NFS mount option rdirplus

NFS mount option rdirplus

[Mora, Jorge]

Hello Trond,

A customer is experiencing significant performance degradation after switching from Rocky Linux 8.7 clients to a 6.12 upstream kernel. The clients with the newer kernel are seeing a dramatic increase in GETATTR/LOOKUP operations. Their workload primarily involves traversing a read-only directory tree and reading or retrieving file attributes.

This issue is related to changes made to add heuristics to READDIRPLUS. We have been testing on RHEL 9.7 using the mount option 'rdirplus=force' to reduce the number of GETATTR/LOOKUP operations. However, this option introduces other issues.

Is it possible to add a mount option to completely bypass the readdir heuristics, such as 'rdirplus=legacy'? Alternatively, could a mount option be added to make the client less aggressive in sending READDIRPLUS requests, such as 'rdirplus=eager'?


--Jorge

Re: NFS mount option rdirplus

[Mora, Jorge]

+Stephen Abbene
+Peter Yoo

--Jorge
________________________________________
From: Mora, Jorge
Sent: Wednesday, July 8, 2026 2:59 PM
To: linux-nfs@vger.kernel.org; Trond Myklebust
Cc: Williams, Keith
Subject: NFS mount option rdirplus

Hello Trond,

A customer is experiencing significant performance degradation after switching from Rocky Linux 8.7 clients to a 6.12 upstream kernel. The clients with the newer kernel are seeing a dramatic increase in GETATTR/LOOKUP operations. Their workload primarily involves traversing a read-only directory tree and reading or retrieving file attributes.

This issue is related to changes made to add heuristics to READDIRPLUS. We have been testing on RHEL 9.7 using the mount option 'rdirplus=force' to reduce the number of GETATTR/LOOKUP operations. However, this option introduces other issues.

Is it possible to add a mount option to completely bypass the readdir heuristics, such as 'rdirplus=legacy'? Alternatively, could a mount option be added to make the client less aggressive in sending READDIRPLUS requests, such as 'rdirplus=eager'?


--Jorge

Re: NFS mount option rdirplus

[Trond Myklebust]

Hi Jorge

On Fri, 2026-07-17 at 16:35 +0000, Mora, Jorge wrote:
> +Stephen Abbene
> +Peter Yoo
> 
> --Jorge
> ________________________________________
> From: Mora, Jorge
> Sent: Wednesday, July 8, 2026 2:59 PM
> To: linux-nfs@vger.kernel.org; Trond Myklebust
> Cc: Williams, Keith
> Subject: NFS mount option rdirplus
> 
> Hello Trond,
> 
> A customer is experiencing significant performance degradation after
> switching from Rocky Linux 8.7 clients to a 6.12 upstream kernel. The
> clients with the newer kernel are seeing a dramatic increase in
> GETATTR/LOOKUP operations. Their workload primarily involves
> traversing a read-only directory tree and reading or retrieving file
> attributes.
> 
> This issue is related to changes made to add heuristics to
> READDIRPLUS. We have been testing on RHEL 9.7 using the mount option
> 'rdirplus=force' to reduce the number of GETATTR/LOOKUP operations.
> However, this option introduces other issues.
> 
> Is it possible to add a mount option to completely bypass the readdir
> heuristics, such as 'rdirplus=legacy'? Alternatively, could a mount
> option be added to make the client less aggressive in sending
> READDIRPLUS requests, such as 'rdirplus=eager'?

We already have 3 different modes for readdirplus: the default
heuristic based rdirplus, off (nordirplus/rdirplus=none) and always on
(rdirplus=force). I'm violently opposed to adding yet another, and
particularly if it is just tagging a slightly different heuristic.

So if you're seeing problems with a read-only directory, then I suggest
you use the tracepoints that are already in the code to show what is
going wrong, and determine why. We can then have an informed discussion
as to whether or not we need to have another round of changes for the
current default heuristics.

That said, if the directory contents are also read-only and not
expected to change, then why can't your customer use statx() with the
AT_STATX_DONT_SYNC flag to just retrieve whatever is currently in the
cache?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com