From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 13:42:11 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 365F916A417; Thu, 15 Nov 2007 13:42:11 +0000 (UTC) (envelope-from tss@iki.fi) Received: from dovecot.org (dovecot.org [82.118.211.50]) by mx1.freebsd.org (Postfix) with ESMTP id E440813C465; Thu, 15 Nov 2007 13:42:10 +0000 (UTC) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id E8A3116471F4; Thu, 15 Nov 2007 15:12:00 +0200 (EET) From: Timo Sirainen To: Robert Watson In-Reply-To: <20071115123543.H82897@fledge.watson.org> References: <20071115074247.GQ37473@egr.msu.edu> <20071115123543.H82897@fledge.watson.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LI7SnER0JCCjBVM+SaL+" Date: Thu, 15 Nov 2007 15:12:00 +0200 Message-Id: <1195132320.6039.135.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Mailman-Approved-At: Thu, 15 Nov 2007 13:54:44 +0000 Cc: Adam McDougall , freebsd-current@FreeBSD.org 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 13:42:11 -0000 --=-LI7SnER0JCCjBVM+SaL+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 te= st=20 > > case that seems to indicate sometimes a link() call can succeed while t= he=20 > > link count of the file will not increase. If this is ran on two FreeBS= D=20 > > clients from the same NFS directory, you will occasionally see "link()=20 > > succeeded, but link count=3D1". I've tried both a Netapp and a FreeBSD= NFS=20 .. > My guess, and this is just a hand-wave, is that the attribute cache in th= e NFS=20 > client isn't being forced to refresh, and hence you're getting the old st= at=20 > data back (and perhaps there's no GETATTR on the wire, which might hint a= t=20 > this). If you'd like, you can post a link to the pcap capture file and o= ne of=20 > us can take a look, but I've found NFS RPCs to be surprisingly readable i= n=20 > 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=3D1 reply. --=-LI7SnER0JCCjBVM+SaL+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHPEWgyUhSUUBViskRAgdUAJ9oxcaapCx9OHuzztVA0DCjGA4VkwCgjZ3j cILNJPWfmbnGnqjX9NPnaxM= =6qV6 -----END PGP SIGNATURE----- --=-LI7SnER0JCCjBVM+SaL+--