[Gluster-devel] Report ESTALE as ENOENT

[Raghavendra Gowdappa]

On Fri, Mar 2, 2018 at 9:46 PM, J. Bruce Fields <bfields at fieldses.org>
wrote:

> On Wed, Feb 28, 2018 at 08:15:13AM +0530, Raghavendra Gowdappa wrote:
> > On Wed, Feb 28, 2018 at 2:49 AM, J. Bruce Fields <bfields at fieldses.org>
> > wrote:
> > > 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....
> > >
> >
> > Its an artificial test.  Not motivated by any user's real world scenario.
> > But, I was not sure whether such a usecase won't be used in realworld
> > workloads. Hence was trying to debug it. Have you seen such realworld
> > workloads on NFS?
>
> Off the top of my head, no.  If somebody did something like an "rm -rf"
> from multiple clients, we'd tell them not to do that.

(Jeff Layton's work to retry ESTALE in the vfs was motivated by a
> slightly different case.  I think it was stat on a file that had been
> atomicly replaced by a rename, so lookup+getattr could return ESTALE on
> the getattr if the replacement happened to intervene between those two
> operations, even though there was never a moment when the given path
> didn't point to a file.)
>

Thanks for that info. There is some progress on the bug. ESTALE error is
because of stale metadata cache within Glusterfs. Glusterfs returned a
successful response for a lookup done in the retry path, even though
previous rmdir had failed to VFS with ESTALE. However, we've still not able
to get the use case working. We seem to be hitting new/different errors.
Will update any progress on this.



>
> --b.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180302/29ce11a4/attachment.html>