Date: Thu, 22 Dec 2016 00:24:41 +0000 From: Colin Percival <cperciva@tarsnap.com> To: Rick Macklem <rmacklem@uoguelph.ca>, Don Lewis <truckman@FreeBSD.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@email.amazonses.com> In-Reply-To: <YTXPR01MB018946842963F9B6A6D39FA4DD930@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> References: <201612210325.uBL3PVtg006345@gw.catspoiler.org> <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> <YTXPR01MB018946842963F9B6A6D39FA4DD930@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/21/16 14:43, Rick Macklem wrote:
>> On 12/20/16 19:25, Don Lewis wrote:
>>> It sort of seems like this should be handled at the vfs level. Once
>>> rmdir() succeeds, there should be no calls to the underlying fs code.
>>> Maybe add a deleted flag to the vnode ...
>>
> As I already mentioned to Colin, there is also the case where another client did the
> "rmdir" and the ESTALE will happen for that case, so mapping ESTALE->ENOENT
> seems to me to be a simple (and maybe more general) solution for NFS.
Except that ENOENT means "the named file does not exist", and ESTALE simply
means "the file which had that name a while ago no longer exists". If you
have one machine which calls open("foo") and another machine which calls
rename("bar", "foo") then you can very reasonably expect to not get ENOENT.
It seems to me that "behave like a local filesystem with respect to other
operations from the same client, but return ESTALE if a different client
rips files/directories out from underneath you" makes more sense than having
ENOENT get returned when there is in fact a file with the specified name.
--
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?0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000>