<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 28, 2018 at 2:49 AM, 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 Mon, Feb 26, 2018 at 11:20:49AM +0530, Raghavendra G wrote:<br>
> On Fri, Feb 23, 2018 at 6:33 AM, J. Bruce Fields <<a href="mailto:bfields@fieldses.org">bfields@fieldses.org</a>><br>
> wrote:<br>
><br>
> > On Thu, Feb 22, 2018 at 01:17:58PM +0530, Raghavendra G wrote:<br>
</span><div><div class="h5">> > > For a local filesystem, we may not end up in ESTALE errors. But, when<br>
> > rmdir<br>
> > > is executed from multiple clients of a network fs (like NFS, Glusterfs),<br>
> > > unlink or rmdir can easily fail with ESTALE as the other rm invocation<br>
> > > could've deleted it. I think this is what has happened in bugs like:<br>
> > > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1546717" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1546717</a><br>
> > > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1245065" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1245065</a><br>
> > ><br>
> > > This in fact was the earlier motivation to convert ESTALE into ENOENT, so<br>
> > > that rm would ignore it. Now that I reverted the fix, looks like the bug<br>
> > > has promptly resurfaced :)<br>
> > ><br>
> > > There is one glitch though. Bug 1245065 mentions that some parts of<br>
> > > directory structure remain undeleted. From my understanding, atleast one<br>
> > > instance of rm (which is racing ahead of all others causing others to<br>
> > > fail), should've delted the directory structure completely. Though, I<br>
> > need<br>
> > > to understand the directory traversal done by rm to find whether there<br>
> > are<br>
> > > cyclic dependency between two rms causing both of them to fail.<br>
> ><br>
> > I don't see how you could avoid that. The clients are each caching<br>
> > multiple subdirectories of the tree, and there's no guarantee that 1<br>
> > client has fresher caches of every subdirectory. There's also no<br>
> > guarantee that the client that's ahead stays ahead--another client that<br>
> > sees which objects the first client has already deleted can leapfrog<br>
> > ahead.<br>
> ><br>
><br>
> What are the drawbacks of applications (like rm) treating ESTALE equivalent<br>
> of ENOENT? It seems to me, from the application perspective they both<br>
> convey similar information. If rm could ignore ESTALE just like it does for<br>
> ENOENT, probably we don't run into this issue.<br>
<br>
</div></div>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></blockquote><div><br></div><div>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?<br></div><div><br></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>