<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 9:46 PM, J. Bruce Fields <span dir="ltr"><<a href="mailto:bfields@fieldses.org" target="_blank">bfields@fieldses.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Feb 28, 2018 at 08:15:13AM +0530, Raghavendra Gowdappa wrote:<br>
> On Wed, Feb 28, 2018 at 2:49 AM, J. Bruce Fields <<a href="mailto:bfields@fieldses.org">bfields@fieldses.org</a>><br>
> wrote:<br>
</span><span class="">> > That might work. Or, maybe better, take "ESTALE" as a sign that the<br>
> > parent directory is gone and give up on trying to remove further entries<br>
> > from it.<br>
> ><br>
> > Could you remind me why this is a priority, anyway? A quick look at the<br>
> > bz's suggest they're both artificial tests. Were they were motivated by<br>
> > a customer problem originally? Apologies if we've already been over<br>
> > this....<br>
> ><br>
><br>
> Its an artificial test. Not motivated by any user's real world scenario.<br>
> But, I was not sure whether such a usecase won't be used in realworld<br>
> workloads. Hence was trying to debug it. Have you seen such realworld<br>
> workloads on NFS?<br>
<br>
</span>Off the top of my head, no. If somebody did something like an "rm -rf"<br>
from multiple clients, we'd tell them not to do that.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Jeff Layton's work to retry ESTALE in the vfs was motivated by a<br>
slightly different case. I think it was stat on a file that had been<br>
atomicly replaced by a rename, so lookup+getattr could return ESTALE on<br>
the getattr if the replacement happened to intervene between those two<br>
operations, even though there was never a moment when the given path<br>
didn't point to a file.)<br></blockquote><div><br></div><div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--b.<br>
</font></span></blockquote></div><br></div></div>