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.) --b. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
