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

Xin LI delphij at gmail.com
Sun Nov 6 03:03:48 UTC 2011


Hi, Rick,

On Sat, Nov 5, 2011 at 6:18 PM, 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.
>
> I wouldn't want this to be the default, but am willing to
> patch head based on the "backwards compatibility" argument.
> My concern with these types of patches is that some people
> will enable them without realizing the risk of data loss
> that they introduce.
>
> So, how do others feel with respect to whether or not this
> patch should be committed to head?

I think the default of old NFS server was async=0?  In general I'd
prefer seeing this as an option but disabled by default, so
administrators can override the option.  Having async=1 by default
doesn't seem to be a good idea in my opinion.

Another thought is the async flag should be a per-mountpoint flag
rather than a global flag, but that might be over-complicating things
so just my $0.02.

Cheers,
-- 
Xin LI <delphij at delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die


More information about the freebsd-fs mailing list