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>
> > 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.)
Gluster-devel mailing list