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

[Ronald Klop]

On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem <rmacklem at uoguelph.ca>  
wrote:

> Hi,
>
> 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  
memory.

Ronald.