link() not increasing link count on NFS server

Robert Watson rwatson at
Mon Nov 26 04:58:31 PST 2007

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

> Robert Watson <rwatson at> 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 

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-current mailing list