[RFC] Should vfs.nfsrv.async be implemented for new NFS server?
ronald-freebsd8 at klop.yi.org
Sun Nov 6 13:31:04 UTC 2011
On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem <rmacklem at uoguelph.ca>
> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist
> for the new NFS server.
> I don't think I had spotted this before, but when I looked I
> saw that, when vfs.nfsrv.async is set non-zero in the old server,
> it returns FILESYNC (which means the write has been committed to
> non-volatile storage) even when it hasn't actually done that.
> This can improve performance, but has some negative implications:
> - If the server crashes before the write is committed to
> non-volatile storage, the file modification will be lost.
> (When a server replies UNSTABLE to a write, the client holds
> onto the data in its cache and does the write again if the
> server crashes/reboots before the client does a Commit RPC
> for the file. However, a reply of FILESYNC tells the client
> it can forget about the write, because it is done.)
> - Because of the above, replying FILESYNC when the data is not
> yet committed to non-volatile (also referred to as stable)
> storage, this is a violation of RFC1813.
Just out of curiosity. Why would lying about FILESYNC improve performance
over UNSTABLE? The server does the same work. Only the client holds data
longer in memory. I only see impact if the client has just a little bit of
More information about the freebsd-fs