From: Jeff Layton <jlayton@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>, Olga Kornievskaia <aglo@umich.edu>
Cc: Scott Mayhew <smayhew@redhat.com>,
anna@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC] NFS: Add some knobs for disabling delegations in sysfs
Date: Tue, 27 Jan 2026 11:04:12 -0500 [thread overview]
Message-ID: <96c77cc077fb3b8ec6c00dd0a712508af8323014.camel@kernel.org> (raw)
In-Reply-To: <e7e87d150b3f070ca872e5cf418331ebf8ed161f.camel@kernel.org>
On Tue, 2026-01-20 at 18:22 -0500, Trond Myklebust wrote:
> On Tue, 2026-01-20 at 15:46 -0500, Olga Kornievskaia wrote:
> > On Mon, Nov 24, 2025 at 8:01 PM Trond Myklebust <trondmy@kernel.org>
> > 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.
> >
> > Hi Trond,
> >
> > Shouldn't open flags be something that's a generic concept for all
> > filesystems? O_DELEGATION seems to be NFS specific (or at most
> > network
> > filesystem specific).
> >
> > > That might also allow someone to add an LD_PRELOAD library to add
> > > or
> > > remove these flags from an existing application's open() calls.
> > >
> > > It might also be useful for the directory delegation functionality
> > > that
> > > Anna and Jeff have been working on...
> >
> > Being able to control directory delegations feature (might be) useful
> > too? We used to be able to toggle features via mount options,
> > wouldn't
> > it be nice if we could again.... Toggling features via sysfs is
> > useful
> > for when mount is already in place though.
> > >
>
> Isn't Jeff Layton in the process of exporting the NFSv4 delegation
> functionality to userspace through the lease mechanisms?
It's not quite the same thing, as they aren't acquired at open time.
Similar to leases, you have to call fcntl(..., F_SETDELEG, ...) to get
one. It doesn't seem like it really meshes with the idea of an
O_NODELEGATION flag.
Being able to disable delegations on a per-mount basis seems like it
could be useful though.
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2026-01-27 16:04 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
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 [this message]
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=96c77cc077fb3b8ec6c00dd0a712508af8323014.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=aglo@umich.edu \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=smayhew@redhat.com \
--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