-
Story
-
Resolution: Not a Bug
-
Undefined
-
None
-
None
-
Important
-
FutureFeature, ZStream, Patch, Upstream
-
Customer Facing
-
rhel-fs
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
Goal
- Continue improving NFS client heuristics to make smarter decisions on whether to use readdir or readdirplus.
When applications read an NFS directory, the layers look like this:
User application
- Linux Virtual File System (VFS)
- NFS client (kernel) --> decides: readdir or readdirplus?
- RPC to NFS server
Readdirplus returns directory entries (like filenames), file attributes, and file handles for each entry. Readdir returns only directory entries.
NFS clients use heuristics to decide whether to use readdir or readdirplus. If an NFS client determines that a calling application needs full information about the file/directory attributes, the NFS client will make a readdirplus call and the NFS server will return full attribute information. If the NFS client determines that a calling application only needs names of files and directories, the NFS client will make a readdir call and the NFS server will return only file and directory names, reducing the number of calls and network traffic required to complete the listing.
Occasionally, those heuristics lead to the wrong choice. If an NFS client uses readdirplus when readdir is more appropriate, it might waste network bandwidth, overload busy NFS servers, or even force unnecessary client cache updates. If an NFS client uses readdir when readdirplus is more appropriate, it might also need to issue getattr or other calls for each directory entry to satisfy the calling application, which increases overhead and hurts performance.
In at least one case, an NFS client heuristics update with RHEL 8.8 triggered a 10x performance hit.
Jira RHEL-16285 worked around the problem with RHEL 8 by offering a new NFS mount parameter, readdirplus=none|force. This mount parameter tells the NFS client to either never or always use readdirplus. The RHEL 9 and 10 NFS clients also merged the same patch.
The workaround is not a universal solution. Some workloads might need readdir sometimes and readdirplus other times. But if the NFS client heuristics make bad decisions, performance will suffer no matter what choice any admin makes for mount parameters.
The NFS client needs to make smarter decisions on whether to use readdir or readdirplus, which will reduce the need to this new mount parameter.
Acceptance criteria
- NFS clients only need a small number of additional GETATTR calls with readdir.
- Good cache and bandwidth utilization with readdirplus.
- No performance hits because improved heuristics always lead to the best readdir vs. readdirplus decision.