Date: Sun, 11 Dec 2016 23:42:33 -0600 From: Benjamin Kaduk <kaduk@mit.edu> To: Colin Percival <cperciva@tarsnap.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <20161212054233.GU8460@kduck.kaduk.org> In-Reply-To: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161212054233.GU8460>