On 03/23/2016 12:07 PM, Ravishankar N wrote:
On 03/23/2016 09:16 PM, Soumya Koduri wrote:
If it occurs only when the file/dir is not actually present at the
back-end, shouldn't we fix the server to send ENOENT then?
I never fully understood it here is the answer:
http://review.gluster.org/#/c/6318/
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.
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.
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.
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.
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)
[1] http://nfs.sourceforge.net/
[2] https://lwn.net/Articles/272684/
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
