From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@kernel.org>, Mike Snitzer <snitzer@kernel.org>
Cc: linux-nfs@vger.kernel.org, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
axboe@kernel.dk
Subject: Re: nfsd: add the ability to enable use of RWF_DONTCACHE for all nfsd IO
Date: Fri, 21 Feb 2025 10:50:58 -0500 [thread overview]
Message-ID: <428799bc-c4d6-4c81-a6bb-bf8a16aa6bb9@oracle.com> (raw)
In-Reply-To: <bb0c5102c1004b896a8d3350dcbea9ba7a8accd3.camel@kernel.org>
On 2/21/25 10:46 AM, Jeff Layton wrote:
> On Fri, 2025-02-21 at 10:39 -0500, Chuck Lever wrote:
>> On 2/21/25 10:02 AM, Mike Snitzer wrote:
>>> On Thu, Feb 20, 2025 at 01:17:42PM -0500, Chuck Lever wrote:
>>>> * It might be argued that putting these experimental tunables under /sys
>>>> eliminates the support longevity question, since there aren't strict
>>>> rules about removing files under /sys.
>>>
>>> Right, I do think a sysfs knob (that defaults to disabled, requires
>>> user opt-in) is a pretty useful and benign means to expose
>>> experimental functionality.
>>
>> Seems like we want to figure out a blessed way to add this kind of
>> experimental "hidden" tunable in a way that can be easily removed
>> once we have the answers we need.
>>
>> I'd really like to keep the documented administrative interface as
>> straightforward as possible, but I agree that having a way to
>> experiment is valuable.
>
> We do have this fancy new netlink interface that is extensible.
>
> You could extend the "threads" call to add a server-wide boolean for
> this and then extend nfsdctl to set that value in some cases.
If we don't have other options that are more familiar outside of
the NFSD world (someone mentioned debugfs), then adding a netlink
operation that is explicitly documented as "access to experimental
temporary features that no-one can rely on existing" seems like a good
alternative. We can make our own rules there.
--
Chuck Lever
next prev parent reply other threads:[~2025-02-21 15:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 17:12 [PATCH] nfsd: add the ability to enable use of RWF_DONTCACHE for all nfsd IO Mike Snitzer
2025-02-20 18:17 ` Chuck Lever
2025-02-21 15:02 ` Mike Snitzer
2025-02-21 15:25 ` Jeff Layton
2025-02-21 15:36 ` Mike Snitzer
2025-02-21 15:42 ` Jeff Layton
2025-02-21 15:46 ` Chuck Lever
2025-02-21 16:13 ` Trond Myklebust
2025-02-21 18:42 ` Jeff Layton
2025-02-21 19:18 ` Trond Myklebust
2025-02-21 15:39 ` Chuck Lever
2025-02-21 15:46 ` Jeff Layton
2025-02-21 15:50 ` Chuck Lever [this message]
2025-02-20 19:00 ` [PATCH] " Jeff Layton
2025-02-20 19:15 ` Chuck Lever
2025-02-21 15:25 ` Mike Snitzer
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=428799bc-c4d6-4c81-a6bb-bf8a16aa6bb9@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Dai.Ngo@oracle.com \
--cc=axboe@kernel.dk \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=snitzer@kernel.org \
--cc=tom@talpey.com \
/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