From: Scott Mayhew <smayhew@redhat.com>
To: Trond Myklebust <trondmy@kernel.org>
Cc: anna@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC] NFS: Add some knobs for disabling delegations in sysfs
Date: Mon, 1 Dec 2025 06:34:44 -0500 [thread overview]
Message-ID: <aS19VL6-SLpejH1r@aion> (raw)
In-Reply-To: <e49d89f7818c72fb3f7bbb2dd90630394c55c0dc.camel@kernel.org>
On Mon, 24 Nov 2025, Trond Myklebust wrote:
> Hi Scott,
>
> On Mon, 2025-11-24 at 19:15 -0500, Scott Mayhew wrote:
> > There's occasionally a need to disable delegations, whether it be due
> > to
> > known bugs or simply to give support staff some breathing room to
> > troubleshoot issues. Currently the only real method for disabling
> > delegations in Linux NFS is via /proc/sys/fs/leases-enable, which has
> > some major drawbacks in that 1) it's only applicable to knfsd, and 2)
> > it
> > affects all clients using that server.
> >
> > Technically it's not really possible to disable delegations from the
> > client side since it's ultimately up to the server whether grants a
> > delegation or not, but we can achieve a similar affect in NFSv4.1+ by
> > manipulating the OPEN4_SHARE_ACCESS_WANT* flags.
> >
> > Rather than proliferating a bunch of new mount options, add some
> > sysfs
> > knobs to allow some of the nfs_server->caps flags related to
> > delegations
> > to be adjusted.
> >
>
> Shouldn't we rather be allowing the application to select whether it
> wants to request a delegation or not?
>
> IOW: while there may or may not be a place for a 'big hammer' solution
> like you propose, should we not rather first try to enable a solution
> in which someone could add a O_DELEGATION or O_NODELEGATION flag to
> open() in order to specify what they want.
>
> That might also allow someone to add an LD_PRELOAD library to add or
> remove these flags from an existing application's open() calls.
Sure, allowing the application to specify whether it wants a delegation
or not would be better... but with open() being governed by POSIX and
with delegations being an NFS-specific feature, I figured adding open
flags related to delegations wasn't feasible. I discussed it with Olga,
and she had the same opinion. Are we mistaken here?
>
> It might also be useful for the directory delegation functionality that
> Anna and Jeff have been working on...
>
> Just some food for thought while you're digesting on Thursday :-)...
>
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trondmy@kernel.org, trond.myklebust@hammerspace.com
>
next prev parent reply other threads:[~2025-12-01 11:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 0:15 [PATCH RFC] NFS: Add some knobs for disabling delegations in sysfs Scott Mayhew
2025-11-25 1:00 ` Trond Myklebust
2025-12-01 11:34 ` Scott Mayhew [this message]
2025-12-01 17:17 ` Trond Myklebust
2026-01-20 20:46 ` Olga Kornievskaia
2026-01-20 23:22 ` Trond Myklebust
2026-01-27 16:04 ` Jeff Layton
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=aS19VL6-SLpejH1r@aion \
--to=smayhew@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