From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 28 12:48:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B798106568F for ; Wed, 28 Oct 2009 12:48:47 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 59F478FC0C for ; Wed, 28 Oct 2009 12:48:39 +0000 (UTC) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.13.7/8.13.7) with ESMTP id n9SCoiRI044255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 14:50:44 +0200 (EET) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id B908E1CC38; Wed, 28 Oct 2009 14:48:32 +0200 (EET) Date: Wed, 28 Oct 2009 14:48:32 +0200 From: Andrey Simonenko To: Linda Messerschmidt Message-ID: <20091028124832.GA7852@pm513-1.comsys.ntu-kpi.kiev.ua> References: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on comsys.ntu-kpi.kiev.ua Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 7.2 + NFS + nullfs + unlink + fstat = Stale NFS File Handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:48:47 -0000 On Tue, Oct 27, 2009 at 01:13:18PM -0400, Linda Messerschmidt wrote: > > Does anyone know what the likely source of this different behavior is, > and whether it is feasible to address? Or is NFS+NULLFS just pushing > the envelope a little too far? As I understand when a file is opened in NULLFS its vnode gets new reference on 'count of users', but this new reference is not propagated to the lower vnode (vnode that is under NULLFS). When a file is removed NULLFS passes this op to the lower FS (NFS in this example) and that FS sees that its vnode has only a single reference on 'count of users'. In case of NFS when there is a request to remove a vnode it checks that value of 'count of users' for this vnode. If this count is equal to 1, then NFS client code does 'RPC remove'. If this count is greater than 1 (for example when a file is opened), then NFS client code renames pathname to .nfs-file, but does not send 'RPC remove' to the NFS server. > > fd = open("testfile", O_RDWR | O_CREAT | O_TRUNC, 0666); > if (!fd) { ^^^^^ should be (fd < 0)