link() not increasing link count on NFS server
tss at iki.fi
Thu Nov 15 06:46:32 PST 2007
On 15.11.2007, at 16.05, Robert Watson wrote:
> 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. It could well be we should be doing
> the same. I've added Mohan to the CC line in case he has any input
> on this point.
A couple of arguments for its removal:
It's somewhat well known that link() can fail with EEXIST even though
it had succeeded (e.g. link(2) man page in Linux mentions it), but I
hadn't before heard that link() could return success even though it
Since link() is often used for creating lock files, it's a lot safer
to fail occationally than to think that the locking succeeded and
cause data corruption.
I've anyway changed my code to work around both problems now (return
0 check in #ifdef __FreeBSD__).
BTW. Another problem I have is that it seems the only way to make
sure open() opens the latest file with the given name is to rmdir()
its parent directory. This isn't very nice to do for directories that
might be empty, so could the code be changed to flush the cache also
when chown()ing the directory or something?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071115/9d61c677/PGP.pgp
More information about the freebsd-current