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