NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram)

Spelic
2010-12-06T12:19:26Z

On 12/06/2010 05:09 AM, Dave Chinner wrote:
>> [Files become sparse at nfs-server-side upon hitting ENOSPC if NFS client uses local writeback caching]
>>
>>
>> It's nice that the NFS server does local writeback caching but it
>> should also cache the filesystem's free space (and check it
>> periodically, since nfs-server is presumably not the only process
>> writing in that filesystem) so that it doesn't accept more data than
>> it can really write. Alternatively, when free space drops below 1GB
>> (or a reasonable size based on network speed), nfs-server should
>> turn off filesystem writeback caching.
>>
> This isn't a NFS server problem, or one that canbe worked around at
> the server. it's a NFS _client_ problem in that it does not get
> synchronous ENOSPC errors when using writeback caching. There is no
> way for the NFS client to know the server is near ENOSPC conditions
> prior to writing the data to the server as clients operate
> independently.
>
> If you really want your NFS clients to behave correctly when the
> server goes ENOSPC, turn off writeback caching at the client side,
> not the server (i.e. use sync mounts on the client side).
> Write performance will suck, but if you want sane ENOSPC behaviour...
>
>

[adding NFS ML in cc]

Thank you for your very clear explanation.

Going without writeback cache is a problem (write performance sucks as
you say), but guaranteeing to never reach ENOSPC also is hardly
feasible, especially if humans are logged at client side and they are
doing "whatever they want".

I would suggest that either be the NFS client to do polling to see if
it's near an ENOSPC and if yes disable writeback caching, or be the
server to do the polling and if it finds out it's near-ENOSPC condition
it sends a specific message to clients to warn them so that they can
disable caching.

Performed at client side wouldn't change the NFS protocol and can be
good enough if one can specify how often freespace should be polled and
what is the freespace threshold. Or with just one value: specify what is
the max speed at which server disk can fill (next polling period can be
inferred from current free space), and maybe also specify a minimum
polling period (just in case).

Regarding the last part of the email, perhaps I was not clear:

> .....
>
>> Holes in a random file!
>> This is data corruption, and nobody is notified of this data
>> corruption: no error at client side or server side!
>> Is it good semantics? How could client get notified of this? Some
>> kind of fsync maybe?
>>
> Use wireshark to determine if the server sends an ENOSPC to the
> client when the first background write fails. I bet it does and that
> your dd write failed with ENOSPC, too. Something stopped it writing
> at 1.9GB....
>

No, in that case I had written 15x100MB which was more than the
available space but less than available+writeback_cache.
So "cat" ended by itself and never got an ENOSPC error but data never
reached the disk at the other side.

However today I found that by using fsync, the problem is fortunately
detected:

# time cat randfile{001..015} | pv -b | dd conv=fsync
of=/mnt/nfsram/randfile
1.46GB
dd: fsync failed for `/mnt/nfsram/randfile': Input/output error
3072000+0 records in
3072000+0 records out
1572864000 bytes (1.6 GB) copied, 20.9101 s, 75.2 MB/s

real 0m21.364s
user 0m0.470s
sys 0m11.440s

so ok I understand that processes needing guarantees on written data
should use fsync/fdatasync (which is good practice also for a local
filesystem actually...)

Thank you