Re: request-route

Casper Dik (casper@HOLLAND.SUN.COM)
Fri, 01 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