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
Current thread:
- Re: request-route Zoltan Hidvegi (Jul 31)
- Re: request-route Theo de Raadt (Aug 01)
- <Possible follow-ups>
- Re: request-route Casper Dik (Aug 01)