Linux NFS development
 help / color / mirror / Atom feed
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>

      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