From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 22:38:16 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6646516A41A; Thu, 15 Nov 2007 22:38:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F55513C442; Thu, 15 Nov 2007 22:38:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <473CCA59.8090304@FreeBSD.org> Date: Thu, 15 Nov 2007 23:38:17 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Timo Sirainen References: <20071115074247.GQ37473@egr.msu.edu> <20071115123543.H82897@fledge.watson.org> <1195132320.6039.135.camel@hurina> In-Reply-To: <1195132320.6039.135.camel@hurina> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam McDougall , freebsd-current@FreeBSD.org, Robert Watson Subject: Re: link() not increasing link count on NFS server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2007 22:38:16 -0000 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