Description of problem: Any application using glfs handles (like NFS-Ganesha) may need to do lookup on each dirent returned by readdir/readdirp operation to create handles. But since the lookup in glusterfs is very costly operation (as need to be sent to all replica bricks), as the directory gets larger or the replica count increases, the time taken for single readdir operation to complete can take hours of time. To avoid that we need an extended readdirp API which can return handles along with dirent stat as part of its reply. With GlusterFS 3.11, we have support for glfs_xreaddirplus() API which returns stat, handles along with dirent entries there by reducing nfs readdir operation latency. This bug is to track that for FSAL_GLUSTER in nfs-ganesha Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Upstream patches to be cherry-picked : https://review.gerrithub.io/298505 https://review.gerrithub.io/374748
From IRC: With this release this option is now turned on by default. When this option is turned off, NFS falls back to standardreaddir instead of readdirp. Turning this off would result in more lookup and stat requests being sent from the client which may impact performance. Above looks good to me.
(In reply to Kaleb KEITHLEY from comment #8) > From IRC: > > With this release this option is now turned on by default. When this > option is turned off, NFS falls back to standardreaddir instead of > readdirp. > Turning this off would result in more lookup and stat requests being sent > from the client which may impact performance. > > > Above looks good to me. Actually the option to turn it off or on is a compiler option IMO. So user/customer cannot consume that option. It is better to not mention it in doc text.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2610