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

Rick Macklem rmacklem at uoguelph.ca
Wed Nov 9 16:09:29 UTC 2011


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.

rick


More information about the freebsd-fs mailing list