[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