[Bugs] [Bug 1499123] Readdirp is considerably slower than readdir on acl clients

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1499123



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/18438 committed in release-3.12 by jiffin
tony Thottan (jthottan at redhat.com) 
------
commit dfd6f6b5f5a1d3ea7c4f0cdeab09effc2c866641
Author: Susant Palai <spalai at redhat.com>
Date:   Mon Aug 7 15:19:47 2017 +0530

    fuse/readdirp: Remove need_lookup from fuse_readdirp_cbk

    background: Various xlators used to populate their ctx, on
    an explicit lookup. That means without a lookup, the translator will have
    either null or stale data to function. E.g. dht would depend on lookup to
    create linkto files on the correct node/hashed subvol, afr would rely on
    this lookup to heal pending data/metadata etc.

    So to complete above actions a lookup used to be issued on files,
    even their inode was populated on a readdirp_cbk. This was done
    by setting the need_lookup flag on all the files those were read
    on readdirp fop.

    We tried a small test on "ACL client". For listing 50k files on root
    itself, it took around 50seconds with readdirp enabled while
    the same operation took 5-6 seconds with readdirp disabled. Both the
    times md-cache was enabled.

    We observed that on the 1st test case (readdirp enabled), post readdirp
    a getxattr is done. The number of getxattr depends on the number of acl
    xattrs (I saw requests on these two: system.posix_acl_default,
    system.posix_acl_access). Since need_lookup flag is set, during
fuse_resolve
    a nameless lookup is executed on the inode(getxattr being inode operation,
    hence the nameless lookup). Since md-cache does not serve nameless lookup,
    a network hop is needed for each file, costing the time.

    With readdirp disabled, the getxattrs are served from md-cache itself(note:
    we are discussing the 2nd attempt of ls -l use case).

    _Current affairs around need of lookup for a file to populate it's ctx_:

    For the xlators on client stack we discussed quite extensively about the
need
    for a lookup fop post readdirp in all three cluster translators - afr, EC
and
    dht. EC and dht don't really need a nameless lookup post readdirp. For afr
too,
    the need for lookup was negated with patch (http://review.gluster.org/6010
- AFRV2),
    where  afr added a function called afr_inode_refresh() which does a lookup
and
    populates its inode context in case a FOP came to AFR without a lookup
being issued
    prior to it.

    We ran a thread on gluster-devel asking for feedback on the need of
explicit lookup
    post readdirp. For responses refer [1]. Refer [2] for discussions happened
on gerrit.
    After gathering inputs from [1] and [2], it looks like there is no xlator
in
    current state that requires an explicit lookup post readdirp to function
properly.

    * A separate similar patch will be sent for gfapi/nfs/nfs-ganesha.

    Note: Only file's inode is built with readdirp.

    [1]
http://lists.gluster.org/pipermail/gluster-devel/2017-August/053505.html
    [2] https://review.gluster.org/#/c/17985/

    > Change-Id: Ie1d68ce7bea5e1f8a1fab9a62217f478322554f5
    > BUG: 1492996
    > Signed-off-by: Susant Palai <spalai at redhat.com>

    Change-Id: Ie1d68ce7bea5e1f8a1fab9a62217f478322554f5
    BUG: 1499123
    Signed-off-by: Susant Palai <spalai at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EAQAZDQ1Vs&a=cc_unsubscribe