On Fri, Mar 2, 2018 at 9:46 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> 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.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
