Re: Report ESTALE as ENOENT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

Regarding, gfapi not honoring the ESTALE errors, I think it would be better to do revalidates upon getting ESTALE. 

Just my 2 cents.

Regards,
Raghavendra


On Thu, Mar 24, 2016 at 10:31 AM, Soumya Koduri <skoduri@xxxxxxxxxx> wrote:
Thanks for the information.

On 03/24/2016 07:34 PM, FNU Raghavendra Manjunath wrote:

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.

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.

NFSv3 rfc [1] mentions that NFS3ERR_STALE is a valid error for REMOVE fop.

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?


Thanks,
Soumya

[1] https://www.ietf.org/rfc/rfc1813.txt (section# 3.3.12)


Regards,
Raghavendra


On Thu, Mar 24, 2016 at 9:51 AM, Shyam <srangana@xxxxxxxxxx
<mailto:srangana@xxxxxxxxxx>> wrote:

    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 <mailto:Gluster-devel@xxxxxxxxxxx>
        http://www.gluster.org/mailman/listinfo/gluster-devel

    _______________________________________________
    Gluster-devel mailing list
    Gluster-devel@xxxxxxxxxxx <mailto: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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux