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

[Rick Macklem]

Ronald Klop wrote:
> 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.
Well, I'm not sure I have an answer. Josh noted that it makes a big
difference for them. Maybe he can elaborate?

One additional effect is that the client in head must do a synchronous
write (with FILESYNC and waiting for the RPC reply) before it can
modify a non-continuous region of the same buffer with respect to
the old dirty byte region. (This happens
frequently during builds, done mostly by the loader, I think?)
If the server replies FILESYNC, then the old dirty byte region is done
(ie. no longer a dirty byte region) so the client doesn't
have to do the synchronous write described above.
I hope that the experimental patch I made available a few days ago,
along with work jhb@ is doing will eventually fix this for the FreeBSD
client, but it won't be in head anytime soon (and who knows what
other clients do?).

rick