Xref: utzoo comp.dcom.lans:993 comp.unix.wizards:6377
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bloom-beacon!gatech!hao!noao!grandi
From: grandi@noao.arizona.edu (Steve Grandi)
Newsgroups: comp.dcom.lans,comp.unix.wizards
Subject: Re: NFS performance: a question
Message-ID: <664@noao.UUCP>
Date: 2 Feb 88 13:51:59 GMT
References: <663@noao.arizona.edu>
Reply-To: grandi@noao.arizona.edu (Steve Grandi)
Organization: National Optical Astronomy Observatories, Tucson AZ
Lines: 22

In article <14163@pyramid.pyramid.com> sas@pyrps5.pyramid.com (Scott Schoenthal) writes:
>Due to the stateless nature of NFS, all write requests received by a
>server must be written synchronously to the disk before they can be
>acknowledged to the client.  If this was not true, the following could happen:
>
>In a UNIX NFS server implmenetation, the inode and block maps must
>also be updated during each synchronous block write.

At the Sun Users Group meeting I heard about one of "hacks" added to Sun OS
and NFS to make NFS performance "good enough" to replace the unloved ND
protocol for booting, paging and swapping.  Consider what happens when
an NFS server makes a write on behalf of a client.  Even the simplest case of
a "replacement"  (a write that does not cause the file to be extended) requires
TWO synchronous writes: one to write the data block and one to update time
fields in the inode.  Thus one of the hacks added to Sun OS 4.0 is to
eliminate updating the inode atime and mtime fields for a "non-extending"
write.  Since client swap space will be contained in pre-allocated files on
the server, you have just eliminated half of this source of overhead for
client paging and swapping in NFS.
-- 
Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228
UUCP: {arizona,decvax,hao,ihnp4}!noao!grandi  or  uunet!noao.arizona.edu!grandi 
Internet: grandi@noao.arizona.edu    SPAN/HEPNET: 5356::GRANDI or DRACO::GRANDI