Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!sun!aeras!elxsi!beatnix!mre
From: mre@beatnix.UUCP (Mike Eisler)
Newsgroups: comp.protocols.nfs
Subject: Re: Suggestion for improved NFS monitoring
Keywords: retries, xids
Message-ID: <1443@elxsi.UUCP>
Date: 9 Dec 88 20:11:32 GMT
References: <773@sequent.cs.qmc.ac.uk>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 56

In article <773@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes:

...

>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

Well, there is a compelling reason to somehow bind retries with
requests, and matching all or part of the transaction ids (xids),
is one way. You want to do this so that old response packets from
a previous operation don't appear on the client's UDP/IP port,
and produce a bad response to a new request.

>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.

You've lost me here. If the client doesn't put the the xid into
network order, then how does the server know where the logical
most and least significant bits are? The client and server have
no idea about each other's byte ordering.

>DOes anyone think this is a good idea? Do you want to be able
>to identify retries on the server?

It would be nice to keep statistics about retries on the server,
especially on a per client basis. (Note that in most NFS
implementations, the client keeps these kind of statistics, but not on
a per server basis). Your method of using the xid amounts to the server
unilaterally enforcing a format to a client generated cookie. This
violates the current NFS spec, if not the RPC spec. If you would like
to see this in the next NFS protocol spec, you ought to contact the NFS
people at Sun. The email address for sending comments on the next
protocol (version 3), is sun!cs, or cs@sun.com.

>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

	-Mike Eisler
	{sun,uunet}!elxsi!mre