Bugtraq: Re: request-route

[casper () HOLLAND SUN COM (Casper Dik)]

> On Tue, 29 Jul 1997, John Macdonald wrote:
> > Eric Bennett wrote :
> > || On Tue, 29 Jul 1997, Zoltan Hidvegi wrote:
> > || > lock files in a world-writable directory from a bourne-shell script.
> > ||
> > || I have done this by creating directories instead of files: only one mkdir
> > || will complete.
> >
> > Nope, you;ve got it backwards.  To begin, the same basic problem
> > applies to both.  If an operation succeeds, but the
> > acknowledgement gets lost on the network, then the time-out
> > cause a retry which will fail because the target item exists.
> I believe that most implementations of NFS maintain a cache of the most
> recent few non-idempotent operations (mkdir, rm, rmdir, etc.) and their
> results; if the request is retried, the result is resent.  Can someone who
> has read the code confirm or deny this?

I can't say I've read the code to "most" NFS implementations, but
you're correct that the idempotency of some operations is improved
by using a request cache.  That doesn't solve all the problems; you can
still overflow that cache and get false NAKs.

Typically, you can check this on your servers w/ "nfsstat -s" and you'll
see something like:

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs
31029587   0          0          0          0          958516     66
Connectionless:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs
502049     0          0          0          0          188        1

(The duplicate request cache is implemented at the RPC layer, not the NFS
layer; that's the layer where the transaction id (xid) lives).

Casper