link() not increasing link count on NFS server
tss at iki.fi
Thu Nov 15 05:42:11 PST 2007
On Thu, 2007-11-15 at 12:39 +0000, Robert Watson wrote:
> > or Solaris NFS clients. Basically, Timo (cc'ed) came up with a small test
> > case that seems to indicate sometimes a link() call can succeed while the
> > link count of the file will not increase. If this is ran on two FreeBSD
> > clients from the same NFS directory, you will occasionally see "link()
> > succeeded, but link count=1". I've tried both a Netapp and a FreeBSD NFS
> My guess, and this is just a hand-wave, is that the attribute cache in the NFS
> client isn't being forced to refresh, and hence you're getting the old stat
> data back (and perhaps there's no GETATTR on the wire, which might hint at
> this). If you'd like, you can post a link to the pcap capture file and one of
> us can take a look, but I've found NFS RPCs to be surprisingly readable in
> Wireshark so you might find it sheds quite a bit of light.
Actually the point was that link() returns success even though in
reality it fails. The fstat() was just a workaround to catch this case
and treat link count 1 as if link() had failed with EEXIST. After that I
had no more problems with locking.
I noticed this first because my dotlocking was failing to lock files
properly. I also added fchown() to flush attribute cache after link()
and before fstat(), it gives the same link count=1 reply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071115/2f773eff/attachment.pgp
More information about the freebsd-current