<div dir="ltr"><br><div>I would still prefer not converting all the ESTALE to ENOENT. I think we need to understand this specific case of parallel rm -rfs getting ESTALE errors and handle it accordingly.</div><div><br></div><div>Regarding, gfapi not honoring the ESTALE errors, I think it would be better to do revalidates upon getting ESTALE. </div><div><br></div><div>Just my 2 cents.</div><div><br></div><div>Regards,</div><div>Raghavendra</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 10:31 AM, Soumya Koduri <span dir="ltr"><<a href="mailto:skoduri@redhat.com" target="_blank">skoduri@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the information.<span class=""><br>
<br>
On 03/24/2016 07:34 PM, FNU Raghavendra Manjunath wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes. I think the caching example mentioned by Shyam is a good example of<br>
ESTALE error. Also User Serviceable Snapshots (USS) relies heavily on<br>
ESTALE errors. Because the files/directories from the snapshots are<br>
assigned a virtual gfid on the fly when being looked up. If those inodes<br>
are purged out of the inode table due to lru list becoming full, then a<br>
access to that gfid from the client, will make snapview-server send<br>
ESTALE and either fuse (I think our fuse xlator does a revalidate upon<br>
getting ESTALE) or NFS client can revalidate via path based resolution.<br>
</blockquote>
<br></span>
So wouldn't it be wrong not to send ESTALE to NFS-clients and map it to ENOENT, as was intended in the original mail.<br>
<br>
NFSv3 rfc [1] mentions that NFS3ERR_STALE is a valid error for REMOVE fop.<br>
<br>
Also (at least in gfapi) the resolve code path doesn't seem to be honoring ESTALE errors - glfs_resolve_component(..), glfs_refresh_inode_safe(..) etc.. Do we need to fix them?<br>
<br>
<br>
Thanks,<br>
Soumya<br>
<br>
[1] <a href="https://www.ietf.org/rfc/rfc1813.txt" rel="noreferrer" target="_blank">https://www.ietf.org/rfc/rfc1813.txt</a> (section# 3.3.12)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Regards,<br>
Raghavendra<br>
<br>
<br>
On Thu, Mar 24, 2016 at 9:51 AM, Shyam <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>> wrote:<br>
<br>
On 03/23/2016 12:07 PM, Ravishankar N wrote:<br>
<br>
On 03/23/2016 09:16 PM, Soumya Koduri wrote:<br>
<br>
If it occurs only when the file/dir is not actually present<br>
at the<br>
back-end, shouldn't we fix the server to send ENOENT then?<br>
<br>
I never fully understood it here is the answer:<br>
<a href="http://review.gluster.org/#/c/6318/" rel="noreferrer" target="_blank">http://review.gluster.org/#/c/6318/</a><br>
<br>
<br>
The intention of ESTALE is to state that the inode#/GFID is stale,<br>
when using that for any operations. IOW, we did not find the GFID in<br>
the backend, that does not mean the name is not present. This hence<br>
means, if you have a pGFID+bname, try resolving with that.<br>
<br>
For example, a client side cache can hang onto a GFID for a bname,<br>
but another client could have, in the interim, unlinked the bname<br>
and create a new file there.<br>
<br>
A presence test using GFID by the client that cached the result the<br>
first time, is an ESTALE. But a resolution based on pGFID+bname<br>
again by the same client would be a success.<br>
<br>
By extension, a GFID based resolution, when not really present in<br>
the backend will return ESTALE, it could very well mean ENOENT, but<br>
that has to be determined by the client again, if possible.<br>
<br>
See "A10. What does it mean when my application fails because of an<br>
ESTALE error?" for NFS here [1] and [2] (there maybe better sources<br>
for this information)<br>
<br>
[1] <a href="http://nfs.sourceforge.net/" rel="noreferrer" target="_blank">http://nfs.sourceforge.net/</a><br>
[2] <a href="https://lwn.net/Articles/272684/" rel="noreferrer" target="_blank">https://lwn.net/Articles/272684/</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br></div></div>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a>><span class=""><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br></span>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a>><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>