Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Dec 2016 20:14:53 +0000
From:      Colin Percival <cperciva@tarsnap.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: ESTALE after cwd deleted by same NFS client
Message-ID:  <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com>
In-Reply-To: <YTXPR01MB01891CB02D5D7BA46579F1BFDD9D0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
References:  <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> <20161212054233.GU8460@kduck.kaduk.org> <01000158f1abc081-d4eddc58-3b4b-41dd-aa1e-0157d2fad812-000000@email.amazonses.com> <20161212163603.GV8460@kduck.kaduk.org> <YQBPR01MB018054EE62DEFDC73784AD9BDD9B0@YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> <YTXPR01MB0189ACD940B7D399A6855CB8DD9A0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <YTXPR01MB01891CB02D5D7BA46579F1BFDD9D0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000>