Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!oliveb!sun!kanawha!cs From: cs@kanawha.Sun.COM (Carl Smith) Newsgroups: comp.protocols.nfs Subject: Re: Suggestion for improved NFS monitoring Keywords: retries, xids Message-ID: <80721@sun.uucp> Date: 9 Dec 88 06:52:49 GMT References: <773@sequent.cs.qmc.ac.uk> <1287@stracs.cs.strath.ac.uk> Sender: news@sun.uucp Reply-To: cs@sun.UUCP (Carl Smith) Organization: Sun Microsystems, Mountain View Lines: 29 > Here's one of the error codes > (what a glorious name!) defined in the new edition of the protocol: > > NFSERR_JUKEBOX = 30 > Slow down, buddy. The server has detected a retransmission > of a request that is already in progress. The error is named after a machine made by Epoch, which uses WORMs for backing store for normal disks, and which they call a jukebox. The delays one encounters when having to fetch data from a CD motivated it. > To get back to William's question, I don't think his idea will need to > see the light of day. To properly adopt it, the NFS protocol would need > to be redefined and Sun have just done that. Actually, the previous suggestion was about detecting RPC retries. The connection with NFS is illusory. > Administrators should just have to > fire up the NFS service and let the protocol figure out for itself just > how fast or slow it should go. [If TCP can do it, why not NFS?] Right. And it now does exactly that. The NFS client code in SunOS 4.1 does dynamic adjustment of retransmission times and sizes of read, readdir, and write requests. We've been able to mount NFS file systems over the ARPANET and do operations without once seeing the dreaded ``NFS server foo not responding'' messages. Carl