Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: request-route
From: casper () HOLLAND SUN COM (Casper Dik)
Date: Fri, 1 Aug 1997 10:24:04 +0200


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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault