From owner-freebsd-fs@freebsd.org Mon Dec 12 05:47:51 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29EDAC7230A for ; Mon, 12 Dec 2016 05:47:51 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0E5C126E for ; Mon, 12 Dec 2016 05:47:50 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-447ff70000005085-91-584e38cd1f85 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C2.11.20613.DC83E485; Mon, 12 Dec 2016 00:42:37 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id uBC5gaOZ007149; Mon, 12 Dec 2016 00:42:37 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uBC5gX5G014610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Dec 2016 00:42:36 -0500 Date: Sun, 11 Dec 2016 23:42:33 -0600 From: Benjamin Kaduk To: Colin Percival Cc: "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <20161212054233.GU8460@kduck.kaduk.org> References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nonvWwi/C4OYPFYujHasYLY49/snm wOQx49N8Fo/5z08yBzBFcdmkpOZklqUW6dslcGVc2ZJUsIOzYs6xQ6wNjDvZuxg5OSQETCS+ H1rJ1MXIxSEk0MYkMbPzOwuEs5FR4uDBbYwQzlUmiWcLvjOBtLAIqEpceXcPzGYTUJFo6L7M DGKLCGhKHJy8kg3EZhYwldjcfxusRljAQuJX/3awGl4BY4mPG7vB4kICcRK3z+xig4gLSpyc +YQFoldL4sa/l0A1HEC2tMTyfxwgYU6BeImGr2/BxogKKEs0zHjAPIFRYBaS7llIumchdC9g ZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mil5pSuokRHKQuyjsYX/Z5H2IU4GBU4uF1 SPWNEGJNLCuuzD3EKMnBpCTKy7gOKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd6WZX4QQb0pi ZVVqUT5MSpqDRUmc91Kme4SQQHpiSWp2ampBahFMVoaDQ0mCd4I5UKNgUWp6akVaZk4JQpqJ gxNkOA/Q8Aaw4cUFibnFmekQ+VOMilLivNEgzQIgiYzSPLheUBKRyN5f84pRHOgVYd6/pkBV PMAEBNf9CmgwE9Dg5/u8QQaXJCKkpBoYcyJjIsoWdB70Wv+CbfLyHKZZ/383ccQ9X2J378yu OZnTHs4sFbM7V/DwN+OvM8/EXE6+3+h1/I7GxJDaPRsdPDkP7573el1+Wu1RWatl1h++VX2K On1aOv7Hv76vN9wvXjGsL7vyNkaT25vhXN23nc28Vd33D7dEPli8ynb3lB+GtZ0TVHi72pRY ijMSDbWYi4oTARTk4gv9AgAA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 05:47:51 -0000 On Sun, Dec 11, 2016 at 11:06:42PM +0000, Colin Percival wrote: > Hi filesystem gurus, > > If I run the following with /nfs/ being an NFS mount: > # mkdir /nfs/foo > # touch /nfs/foo/bar > # cd /nfs/foo > # rm -r /nfs/foo > # rm bar > > Then the final 'rm bar' fails with 'Stale NFS file handle'. This results > in 'make buildworld' with an NFS-backed /usr/obj failing during cleandir > (which, for some reason, seems to delete the same directories multiple > times.) > > I'm not sure if this is an NFS issue or a VFS issue, nor whether this is > intended (but IMHO astonishing) behaviour or a bug. > > I realize that if the 'rm -r' was performed by a different NFS client, this > is the behaviour which would be expected; but it seems to me that when the > commands are executed by the same NFS client, it should be possible for the > cached file handle for /nfs/foo to be invalidated when /nfs/foo is deleted, > in order to return ENOENT instead of ESTALE here. Amusingly, this just came up recently: https://www.ietf.org/mail-archive/web/nfsv4/current/msg15115.html (et seq) But I guess you did not specify which version of the NFS protocol you were using... -Ben