[5067] in bugtraq
Re: request-route
daemon@ATHENA.MIT.EDU (Casper Dik)
Fri Aug 1 14:06:26 1997
Date: Fri, 1 Aug 1997 10:24:04 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Wed, 30 Jul 1997 23:05:38 EDT."
<Pine.SUN.3.95.970730225821.10403A-100000@picard.dnaco.net>
>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
