Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!ukc!strath-cs!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.protocols.nfs Subject: Re: Suggestion for improved NFS monitoring Keywords: retries, xids Message-ID: <1287@stracs.cs.strath.ac.uk> Date: 6 Dec 88 12:23:58 GMT References: <773@sequent.cs.qmc.ac.uk> Reply-To: jim@cs.strath.ac.uk Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland. Lines: 57 In article <773@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes: >... Suggesting a scheme for determining retried NFS request packets. >1) All original xids have most & least significant byte = zero >2) All retry xids have most and least significant byte = ones >Does anyone think this is a good idea? Do you want to be able >to identify retries on the server? I don't think this is a bad idea, but I don't think it would help much. The real problem with NFS is the absence of almost any flow-control at any stage of the protocol stack - ISO Reference Model or ARPA Reference Model, call it what you like. The NFS protocol should *somewhere* provide a means for clients and servers to say "slow down, you're going too fast for me". Where this should go is a religious issue - my preference would be for something at the UDP/transport level. Naturally, any notion of flow control further complicates the 'statelessness' of an NFS server. I see that Version 3 of the NFS protocol has now been published. I've not had a chance to look at it in detail yet. It does appear to go some way towards dealing with this problem. 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. As far as I can see, the spec. doesn't say what a client should do (or not do) when it gets this error returned. Worse, there doesn't appear to be any way that a client can ask the server to slow down, though an overloaded NFS client should not be as much of a problem as an overloaded server. 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. The new version of NFS has something about flow control. [Though it appears at first glance that clients are free to ignore "slow down" messages from the servers.] Hopefully the new protocol will go some way to make NFS more usable in a genuinely heterogeneous environment. 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?] It is just not reasonable for users or system administrators to have to tinker with things like numbers of biod and nfsd processes or experiment with the increasingly more baroque options that are kludged into NFS mounts. Jim -- ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"