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

Rick Macklem rmacklem at uoguelph.ca
Sun Nov 6 16:02:21 UTC 2011


Xin Li wrote:
> 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.
> 
Yes, I agree. If I commit it, it will definitely not be enabled by
default. The question I was asking was "Should it be committed at all?".

> 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.
> 
Well, since it doesn't affect server file system behaviour and only the
reply the NFS server sends to the client, I don't see it as a per-mountpoint
flag on server file systems, but I'm really looking for what others
think?

> 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