From: Benjamin Coddington <bcodding@redhat.com>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH v4 0/1] Mount option rdirplus extension
Date: Thu, 13 Mar 2025 13:01:21 -0400 [thread overview]
Message-ID: <cover.1741885071.git.bcodding@redhat.com> (raw)
v2 - Instead of adding "force_rdirplus", extend rdirplus=force
v3 - Fix broken bitwise operator
v4 - Fix /another/ borken bitwise op, reorder option emit
-------------
After these two changes:
1a34c8c9a49e NFS: Support larger readdir buffers
and
85aa8ddc3818 NFS: Trigger the "ls -l" readdir heuristic sooner
.. we've disadvantaged/regressed some users workloads where the user is
forced to use NFSv3 (such that we cannot prime the dcache with d_type on
READDIR as we do for NFSv4), and where the workload is a search through a
large directory tree. Previously, the smaller buffers and/or the larger
heuristic size worked to their advantage to optimize the client toward the
READDIRPLUS path.
We've been able to relieve some pain temporarily by putting a knob into
sysfs to allow them to set the operation to one of:
- force READDIRPLUS
- disable READDIRPLUS
- use the default heurstic
That's exactly the solution they're looking for and we have most of that in
mount options today with the "rdirplus" and "nordirplus". Missing only is
the option to force the client to always use READDIR plus. What follows is
a patch to do that by extending the existing rdirplus mount option to take
values. I'll follow this up with a man page update to nfs-utils.
The global heuristic is always going to be wrong for some workloads and we
cannnot depend on something like a mount-wide option to always work well for
mixed workloads on the same mount. A realistic long-term solution involves
allowing the applications to signal their intended behavior.
So, I am going to look at plumbing in a posix_fadvise() flag for
READDIRPLUS. There's been some interest expressed already for other
filesystems[1]. I plan to send along patches for this and face the
discussions. However, that work will take some time to filter up into the
utilities and into distros. In the meantime, I hope we can add this simpler
mount option to help the folks that need the old behaviors in recent
kernels.
[1]: https://lore.kernel.org/linux-fsdevel/CAOQ4uxhBWV3DfqaE=reuPjh8w92wwujA6Abj=Gt0YvapR4m_1g@mail.gmail.com/
Benjamin Coddington (1):
NFS: Extend rdirplus mount option with "force|none"
fs/nfs/dir.c | 2 ++
fs/nfs/fs_context.c | 32 ++++++++++++++++++++++++++++----
fs/nfs/super.c | 1 +
include/linux/nfs_fs_sb.h | 1 +
4 files changed, 32 insertions(+), 4 deletions(-)
base-commit: 2408a807bfc3f738850ef5ad5e3fd59d66168996
--
2.47.0
next reply other threads:[~2025-03-13 17:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 17:01 Benjamin Coddington [this message]
2025-03-13 17:01 ` [PATCH v4 1/1] NFS: Extend rdirplus mount option with "force|none" Benjamin Coddington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1741885071.git.bcodding@redhat.com \
--to=bcodding@redhat.com \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox