<div dir="ltr"><div>Hi,<br></div>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&#39;s (l)stat system call and while .glusterfs is heavily loaded kernel takes time to lookup inode and due to that performance drops<br>To improve the same we tried two things with this patch(<a href="https://review.gluster.org/#/c/glusterfs/+/23783/">https://review.gluster.org/#/c/glusterfs/+/23783/</a>)<br><br>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<br><br>2) We tried using &quot;at&quot; based call(lstatat,fstatat,readlinat etc) instead of accessing complete path access relative path, these call&#39;s were also helpful to improve performance.<br><div><br></div><div>Regards,</div><div>Mohit Agrawal</div><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre></div></div>