Date: Tue, 13 Dec 2016 14:09:54 +0000 From: Doug Rabson <dfr@rabson.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Benjamin Kaduk <kaduk@mit.edu>, Colin Percival <cperciva@tarsnap.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <CACA0VUgPbOOj=ephABpxLQ7yPRL4604Lj_w6KOxOuwskAsg7XQ@mail.gmail.com> In-Reply-To: <YQBPR01MB018054EE62DEFDC73784AD9BDD9B0@YQBPR01MB0180.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>
next in thread | previous in thread | raw e-mail | index | archive | help
OPEN4_RESULT_PRESERVE_UNLINKED is described in the NFSv4.1 RFC On 13 December 2016 at 13:04, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Benjamin Kaduk wrote: > > >On Mon, Dec 12, 2016 at 06:15:14AM +0000, Colin Percival wrote: > >> On 12/11/16 21:42, Benjamin Kaduk 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 > If this is happening on a single client, something is broken. > - For this step, the name cache should have a miss and the Lookup should > fail with > ENOENT. I think the most likely failures are... > --> Either the name cache in the client is broken and has a hit > OR > --> The server replies NFS_OK for the lookup, even though it should have > been removed. > > When I get home on the weekend, I'll try this against a FreeBSD and Linux > server, to see > if it fails. If it does, then I'll try to figure out why. > (Version of NFS shouldn't matter for this case. They recently added the > optional case > of a server that can retain files after an NFSv4 Remove until the NFSv4 > Close, making > it more POSIX like. I think that's NFSv4.2, but it might be in NFSV4.1.) > > Did you try: > sysctl debug.disable_vnfullpath=1 (or something close to > disable_vnfullpath) > to see if it helped? > > rick > > >> >> > >> >> Then the final 'rm bar' fails with 'Stale NFS file handle'. > >> > > >> > 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... > >> > >> I'm using NFSv4.1, but this isn't quite the same... that link refers to > having > >> one NFS client remove a file out from underneath a different client, > while I'm > >> talking about having an NFS client remove a file from underneath > *itself*. > > > >I thought the reply mentioned (in passing) the case of a client removing a > >file out from under itself as well. But, maybe I was reading too fast. > > > >-Ben > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACA0VUgPbOOj=ephABpxLQ7yPRL4604Lj_w6KOxOuwskAsg7XQ>