Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!uwmcsd1!marque!uunet!mcvax!ukc!harrier.ukc.ac.uk!eagle.ukc.ac.uk!icdoc!qmc-cs!liam From: liam@cs.qmc.ac.uk (William Roberts) Newsgroups: comp.protocols.nfs Subject: Suggestion for improved NFS monitoring Keywords: retries, xids Message-ID: <773@sequent.cs.qmc.ac.uk> Date: 5 Dec 88 12:43:39 GMT Reply-To: liam@cs.qmc.ac.uk (William Roberts) Organization: CS Dept, Queen Mary College, University of London, UK. Lines: 32 Expires: References: Sender: Followup-To: The NFS protocol requests are largely idempotent, so retries do not need to be distinguished from first attempts (though unlink is not idempotent and so needs a chace of recent attempts). However, for tuning NFS it would be very useful to know how many retries your servers were processing in order to experiment with more nfsds, fewer biods or longer timeouts. All RPC requests are marked with an identifier (xid) so that incoming replies can be matched with requests. Currently most NFS clients require that the reply xid exactly match the request xid, and don't change the xid on retries, but there is no compelling reason for this to be so. I suggest the following way of marking retries: 1) All original xids have most & least significant byte = zero 2) All retry xids have most and least significant byte = ones The reason for using both the most and least significant bytes rather than just a single bit is that I want to detect these on the server, and there is no reason why the client should waste time putting its xids into network order - this means that the least significant bit (bit 0) might turn up as bit 24 on some systems. DOes anyone think this is a good idea? Do you want to be able to identify retries on the server? -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250