[Gluster-devel] Report ESTALE as ENOENT

[J. Bruce Fields]

On Mon, Feb 26, 2018 at 11:20:49AM +0530, Raghavendra G wrote:
> On Fri, Feb 23, 2018 at 6:33 AM, J. Bruce Fields <bfields at fieldses.org>
> wrote:
> 
> > On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:
> > > For a local filesystem, we may not end up in ESTALE errors. But, when
> > rmdir
> > > is executed from multiple clients of a network fs (like NFS, Glusterfs),
> > > unlink or rmdir can easily fail with ESTALE as the other rm invocation
> > > could've deleted it. I think this is what has happened in bugs like:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1546717
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1245065
> > >
> > > This in fact was the earlier motivation to convert ESTALE into ENOENT, so
> > > that rm would ignore it. Now that I reverted the fix, looks like the bug
> > > has promptly resurfaced :)
> > >
> > > There is one glitch though. Bug 1245065 mentions that some parts of
> > > directory structure remain undeleted. From my understanding, atleast one
> > > instance of rm (which is racing ahead of all others causing others to
> > > fail), should've delted the directory structure completely. Though, I
> > need
> > > to understand the directory traversal done by rm to find whether there
> > are
> > > cyclic dependency between two rms causing both of them to fail.
> >
> > I don't see how you could avoid that.  The clients are each caching
> > multiple subdirectories of the tree, and there's no guarantee that 1
> > client has fresher caches of every subdirectory.  There's also no
> > guarantee that the client that's ahead stays ahead--another client that
> > sees which objects the first client has already deleted can leapfrog
> > ahead.
> >
> 
> What are the drawbacks of applications (like rm) treating ESTALE equivalent
> of ENOENT? It seems to me, from the application perspective they both
> convey similar information. If rm could ignore ESTALE just like it does for
> ENOENT, probably we don't run into this issue.

That might work.  Or, maybe better, take "ESTALE" as a sign that the
parent directory is gone and give up on trying to remove further entries
from it.

Could you remind me why this is a priority, anyway?  A quick look at the
bz's suggest they're both artificial tests.  Were they were motivated by
a customer problem originally?  Apologies if we've already been over
this....

--b.