[RFC] Should vfs.nfsrv.async be implemented for new NFS server?

[Ivan Voras]

On 9 November 2011 17:09, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> Ivan Voras wrote:
> [good stuff snipped for brevity]
>>
>> This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC
>> that does that manually? If it does, then I don't think there are any
>> differences between doing a write() on a local file system with e.g.
>> soft-updates enabled and doing a write on a NFS file system - in both
>> cases, no data is even remotely guaranteed to survive a crash unless a
>> fsync (or equivalent operation) was issued.
>>
> I think you have to be a bit careful when an assumption about loss of
> data after a crash is applied to a file server. If a client crashes,
> everyone pretty much assumes that recently written data might have been
> lost (in a Unix-like world, at least) and the crash is visible to users.
>
> However, take the following scenario:
> - User on desktop client edits a document for an hour, then saves it.
>  --> NFS server crashes/reboots just after the "save".
> - User on desktop client goes off reading email for an hour, using a
>  mail system not affected by the NFS server crash/reboot.
> - User goes back to document and finds an old damaged document file.
>  --> User is very upset...
>
> My point is that a user on a client may not even realize the server
> crashed/rebooted. The above case can happen if async!=0, but not if
> async==0.

Thank you for the excellent explanation! I see the problem but I think
it is still well within the judgement call of the system
administrator. It should probably not be the default (though I recall
from some benchmarks way back that it might be the default on Linux)
but it should definitely exist as an option.

Thanks again!