From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 14:47:20 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 7867916A417 for ; Fri, 16 Nov 2007 14:47:18 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 0459913C468 for ; Fri, 16 Nov 2007 14:47:17 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id lAGEl4Ec005030; Fri, 16 Nov 2007 14:47:04 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1It2TI-000429-9c; Fri, 16 Nov 2007 14:47:04 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.1/8.14.1) with ESMTP id lAGEl011064584; Fri, 16 Nov 2007 14:47:00 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.1/8.14.1/Submit) id lAGEl0Oi064583; Fri, 16 Nov 2007 14:47:00 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Robert Watson In-Reply-To: <20071115135734.O82897@fledge.watson.org> References: <20071115074247.GQ37473@egr.msu.edu> <20071115123543.H82897@fledge.watson.org> <1195132320.6039.135.camel@hurina> <20071115135734.O82897@fledge.watson.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 16 Nov 2007 14:46:59 +0000 Message-Id: <1195224419.63470.1.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Timo Sirainen , freebsd-current@freebsd.org, Adam McDougall , mohans@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: Fri, 16 Nov 2007 14:47:20 -0000 On Thu, 2007-11-15 at 14:05 +0000, Robert Watson wrote: > On Thu, 15 Nov 2007, 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. > > 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. Small point - NetBSD does seem to still have this code, but they have factored it out into a nfs_linkrpc function. I'm not saying it's correct, however... Gavin