🚀 go-pugleaf

In article <1993Jan4.175456.20845@spectrum.xerox.com> weltman@adoc.xerox.com (Rob Weltman) writes:

>   I received a number of informative responses to my question
> about why large NFS writes are so slow, and a few suggestions on
> how to improve performance, and where to look for more info on
> tuning NFS. The following are all the responses (hope that's OK
> to post; everybody responded directly to me, so people on the
> net can't really know what's been communicated).
> 
> Rob
> 

For the sake of completeness, I would like to add a few comments to
one of Guy Harris' very informative answers, partly cited below:

>> 
>> From auspex.com!guy Thu Dec 31 11:08:24 1992
>> From:	guy@auspex.com (Guy Harris)
>> To:	jmm@imatron.com
>> Subject: Re:  NFS and RPC discussion.
>> Cc:	weltman@parc.xerox.com
>> Status: RO
>> Content-Length: 5983
>> X-Lines: 116
>>
>> [stuff deleted]
>>
>> Normally, at least on most UNIX systems, "some form of storage that
>> survives a server crash" means "the disk", because the UNIX buffer cache
>> or page pool is *not* necessarily preserved if the system crashes and
>> reboots (although a crash *might* cause the OS to try to sync data out
>> to disk, that isn't guaranteed to work).
>> 
>> The Prestoserve board acts as "some form of storage that survives a
>> server crash", but can be written to faster than can a disk; it's static
>> RAM with a battery backup (so that even if the crash is caused by a
>> power failure, the data will still survive the crash).
>> 
>> Some vendors, including SGI, HP, and Auspex, have an *option* for their
>> NFS server code that allows the system administrator to specify that
>> writes to a particular file system by the NFS server should *not* wait
>> until the data makes it to "some form of storage that survives a server
>> crash" before being marked as "done". 

True. However, if not exactly documented, it's piece-of-cake to patch up this 
functionality on any UNIX system with NFS code derived from the original SUN 
src. The patch can be applied directly to the binaries. (in fact, we use 
Emacs for this purpose ..) The NFS server source-module in question is 
'nfs_server.c', and all that needs to be done is to change the flag 
IO_SYNC (=4)  to zero, two or three places down the code if I remember right. 

As said above, the net effect is that NFS writes are now asynchronous, more 
or less like local buffered writes. Instead of the (expensive?)
Prestoserve card, you are now using the server's buffer cache for
write caching, of course with the potential (but small) risk of loosing data 
when the server crashes.

We have been running with this patch on all our DECstation and SPARC
NFS servers for long time now, and have encountered no problems due to
server crashes so far. Initially, we ran the original Legato NFS
benchmark (nhfsstone) and measured NFS write throughput with the patch
installed and compared the results with those supplied by Legato to
document the functionality of the Prestoserve card. Not surprisingly,
the throughput was equally good (and even slightly better some times).
And the interactive performance improvement is really BIG, believe me!

>> We (Auspex) do not make that the default; we use it here only for
>> diskless clients' swap space.  SGI *does* make it the default, claiming
>> that crashes are rare enough that you're not actually going to lose any
>> data.  Sun and SGI folk spend a fair bit of time yelling at one another
>> about this....
>> 

Yes they do, and rumours says that when speaking of NFS "write-security", 
the SGI folks thinks it's better to have UDP checksumming turned *ON* 
than running with the IO_SYNC flag set. Although affecting NFS performance,
this is another issue though.

 ! Steinar Kjaernsroed	Dpt. of Informatics	email:steinar@ifi.uio.no
 !			University of Oslo,               or
 |                      NORWAY                        ..!mcsun!ifi!steinar