Re: link() not increasing link count on NFS server

On Mon, 26 Nov 2007, Dag-Erling Smørgrav wrote:

> Robert Watson <rwatson_at_FreeBSD.org> writes:
>> Indeed, and inspection of nfs_vnops.c:nfs_link(): finds:
>>
>> 1772         /*
>> 1773          * Kludge: Map EEXIST => 0 assuming that it is a reply to a retry.
>> 1774          */
>> 1775         if (error == EEXIST)
>> 1776                 error = 0;
>> 1777         return (error);
>>
>> Neither Linux nor Solaris appears to have this logic in the client.  I
>> assume this is, as suggested, to work around UDP retransmissions where
>> the reply is lost rather than the request.  It appears to exist in
>> revision 1.1 of nfs_vnops.c, so came in with 4.4BSD in the initial
>> import, but doesn't appear in NetBSD so I'm guessing they've removed
>> it.
>
> Wrong, it still exists in NetBSD, but they've separated part of nfs_link() 
> (including that bit) out into nfs_linkrpc().  They also seem to have added 
> logic to detect a retransmit:
>
>        /*
>         * Kludge: Map EEXIST => 0 assuming that it is a reply to a retry.
>         */
>        if (rexmit && error == EEXIST)
>                error = 0;

Indeed, a later post also pointed this out.

> revision 1.197 date: 2004/05/10 10:40:42;  author: yamt;  state: Exp; 
> lines: +32 -25
> don't do kludge for a reply to a retransmitted request unless we actually 
> retransmitted the request.

While their workaround is better than our workaround, is there reason to 
believe that a request is more likely to be dropped than a reply, and that 
their workaround is therefore better than no workaround?  The case I have in 
mind is the one in which EEXIST is, in fact, the expected and desirable result 
of the original request, now dropped, or the retransmitted request, which gets 
through.

Robert N M Watson
Computer Laboratory
University of Cambridge