Timo Sirainen wrote:
> 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.


Is it failing (leaving the link count unchanged, when fstat()'ed on the
server), or is it just returning a stale link count when the *client*
runs fstat()?

There is at least one race with the NFS attribute cache that sometimes
returns old data to clients when they stat a file that has been recently
modified.

Kris

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"