ESTALE after cwd deleted by same NFS client
Colin Percival
cperciva at tarsnap.com
Fri Dec 16 20:15:02 UTC 2016
On 12/15/16 15:17, Rick Macklem wrote:
>>>>>> On Sun, Dec 11, 2016 at 11:06:42PM +0000, Colin Percival wrote:
>>>>>>> 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
>
> I will try and play with this when I get home, but you could test the following
> simple change: (I'll just explain the patch, since I don't have sources handy)
> In sys/fs/nfsclient/nfs_clvnops.c:
> Line #s 1678, 1679 (for remove) and 2180, 2181 (for rmdir) look like:
> if (error == ENOENT)
> error = 0;
> This is done since, if it doesn't exist, it has been "removed".
> It seems to me that ESTALE means it has been removed too.
> (Actually the directory the name was in has been removed, but that implies that
> the name is gone too.)
This doesn't fix the problem. This particular ESTALE is coming earlier, from
nfsrpc_lookup, when we attempt to look up a path relative to a directory which
no longer exists (and thus through a file handle which is stale).
Interestingly, making this change in nfs_lookup
> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132)
> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy)
> @@ -1144,7 +1144,7 @@
> *vpp = NULLVP;
> }
>
> - if (error != ENOENT) {
> + if (error != ENOENT && error != ESTALE) {
> if (NFS_ISV4(dvp))
> error = nfscl_maperr(td, error, (uid_t)0,
> (gid_t)0);
fixes the case I described above (for some definition of "fixes" -- I'm not
sure if this is the correct way of handling ESTALE here?) but I'm still seeing
ESTALEs from buildworld's cleandir so I think there must be some other place
where something odd is happening.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
More information about the freebsd-fs
mailing list