Fixes to allow write clustering of NFS writes from a FreeBSD NFS client

[Bob Friesenhahn]

On Thu, 25 Aug 2011, John Baldwin wrote:

> I was doing some analysis of compiles over NFS at work recently and noticed
> from 'iostat 1' on the NFS server that all my NFS writes were always 16k
> writes (meaning that writes were never being clustered).  I added some
> debugging sysctls to the NFS client and server code as well as the FFS write
> VOP to figure out the various kind of write requests that were being sent.  I
> found that during the NFS compile, the NFS client was sending a lot of
> FILESYNC writes even though nothing in the compile process uses fsync().

A fundamental principle of NFS is that writes are synchronous so that 
if the server spontaneously reboots, all the acknowledged writes will 
still be present on disk and the client just continues (after a delay) 
without loss/corruption of data.  NFSv3 added the ability to send 
uncommitted data to the server, with the agreement that the client 
would agree to re-send any uncommitted data if the server 
spontaneously rebooted.  Most clients are not responsibly prepared to 
participate in this since it would require some non-volatile local 
storage on the client.

I don't know if your changes would harm these expectations.

Regardless, there is little doubt that the default client NFS in 
FreeBSD 8.2 suffers quite a lot in sequential write performance as 
compared with an OS like Solaris.  Hopefully the new NFS that Rick 
Macklem has been working on (and is apparently ready for general use) 
will perform much better.  Since FreeBSD is switching to the new 
implementation it seems like that is where the efforts should be 
going.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/