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 <bfie...@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.)

--b.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Reply via email to