<div dir="ltr"><br><div>Yes. I think the caching example mentioned by Shyam is a good example of ESTALE error. Also User Serviceable Snapshots (USS) relies heavily on ESTALE errors. Because the files/directories from the snapshots are assigned a virtual gfid on the fly when being looked up. If those inodes are purged out of the inode table due to lru list becoming full, then a access to that gfid from the client, will make snapview-server send ESTALE and either fuse (I think our fuse xlator does a revalidate upon getting ESTALE) or NFS client can revalidate via path based resolution.</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 9:51 AM, Shyam <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</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 03/23/2016 12:07 PM, Ravishankar N wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/23/2016 09:16 PM, Soumya Koduri wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it occurs only when the file/dir is not actually present at the<br>
back-end, shouldn't we fix the server to send ENOENT then?<br>
</blockquote>
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>
</blockquote>
<br></span>
The intention of ESTALE is to state that the inode#/GFID is stale, when using that for any operations. IOW, we did not find the GFID in the backend, that does not mean the name is not present. This hence 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, but another client could have, in the interim, unlinked the bname and create a new file there.<br>
<br>
A presence test using GFID by the client that cached the result the first time, is an ESTALE. But a resolution based on pGFID+bname again by the same client would be a success.<br>
<br>
By extension, a GFID based resolution, when not really present in the backend will return ESTALE, it could very well mean ENOENT, but 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 ESTALE error?" for NFS here [1] and [2] (there maybe better sources 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><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<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>
</blockquote>
_______________________________________________<br>
Gluster-devel mailing list<br>
<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>
</div></div></blockquote></div><br></div>