From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 14:05:40 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 51F1616A41A for ; Thu, 15 Nov 2007 14:05:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF7513C48A for ; Thu, 15 Nov 2007 14:05:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9EEF446E80; Thu, 15 Nov 2007 09:07:30 -0500 (EST) Date: Thu, 15 Nov 2007 14:05:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Timo Sirainen In-Reply-To: <1195132320.6039.135.camel@hurina> Message-ID: <20071115135734.O82897@fledge.watson.org> References: <20071115074247.GQ37473@egr.msu.edu> <20071115123543.H82897@fledge.watson.org> <1195132320.6039.135.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adam McDougall , freebsd-current@FreeBSD.org, 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: Thu, 15 Nov 2007 14:05:40 -0000 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. I've added Mohan to the CC line in case he has any input on this point. Robert N M Watson Computer Laboratory University of Cambridge