[Gluster-devel] following up on the work underway for improvements in ls-l - looking for the data on the test runs

Mohit Agrawal moagrawa at redhat.com
Tue Feb 25 07:59:26 UTC 2020


Hi,
We observed performance is mainly hurt while .glusterfs is having huge
data.As we know before executing a fop in POSIX xlator it builds an
internal path based on GFID.To validate the path it call's (l)stat system
call and while .glusterfs is heavily loaded kernel takes time to lookup
inode and due to that performance drops
To improve the same we tried two things with this patch(
https://review.gluster.org/#/c/glusterfs/+/23783/)

1) To keep the first level entry always in a cache so that inode lookup
will be faster       we have to keep open first level fds(00 to ff total
256) per brick at the time of starting a brick process. Even in case of
cache cleanup kernel will not evict first level fds from the cache and
performance will improve

2) We tried using "at" based call(lstatat,fstatat,readlinat etc) instead of
accessing complete path access relative path, these call's were also
helpful to improve performance.

Regards,
Mohit Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20200225/00b941ac/attachment.html>


More information about the Gluster-devel mailing list