linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"jlayton@kernel.org" <jlayton@kernel.org>
Cc: "rick.macklem@gmail.com" <rick.macklem@gmail.com>
Subject: Re: when should the client request a directory delegation?
Date: Wed, 7 Feb 2024 14:56:56 +0000	[thread overview]
Message-ID: <1fac8e86eae132499cc1bffe139ba397293bea9f.camel@hammerspace.com> (raw)
In-Reply-To: <71e5d519411330ee608415fa629322fc84de8139.camel@hammerspace.com>

On Wed, 2024-02-07 at 14:21 +0000, Trond Myklebust wrote:
> On Wed, 2024-02-07 at 08:34 -0500, Jeff Layton wrote:
> > I've started work on a patchset to add support for directory
> > delegations
> > to the Linux kernel client and server. It's still too rough to post
> > at
> > this point, and for now, I'm just cobbling in a ioctl to drive it.
> > 
> > As I started working on some of the client bits, however, I
> > realized
> > that I don't really have a clear picture as to when the client
> > should
> > request a delegation on a directory. It seems like there are a lot
> > of
> > things we could do:
> > 
> > One idea: request one on an initial directory readdir. So maybe
> > when
> > the
> > offset is 0 and we don't have a dir delegation already, do:
> > 
> > 	PUTFH:GET_DIR_DELEGATION:READDIR
> > 
> > Or, maybe just do it on any readdir when we haven't requested one
> > in
> > a
> > little while?
> > 
> > We could also do one on every lookup, when we expect that the
> > result
> > will be a directory. I'm not sure if LOOKUP_DIRECTORY would be a
> > sufficient indicator or if we'd need the vfs to indicate that with
> > a
> > new
> > flag.
> > 
> > Would we also want to request one after a mkdir?
> > 
> > 	PUTFH:CREATE:GET_DIR_DELEGATION:GETFH:GET_DIR_DELEGATION:.
> > ..
> > 
> > Assuming we can get this all working, what should drive the client
> > to
> > issues GET_DIR_DELEGATION ops?
> 
> As far as I'm concerned, the main case to be made for directory
> delegations in the client is for reducing the number of revalidations
> on said directory, particularly during path lookups.
> i.e. the goal is to eliminate the need to constantly poll the
> directory
> change attribute, and to eliminate the need to constantly revalidate
> the dentries (and negative dentries!) contained in the directory
> after
> a change.
> 
> Perhaps that means we should focus on adding a request for a
> directory
> delegation to the function nfs_lookup_revalidate() since that would
> seem to indicate that we're going through the same directory multiple
> times? The other call site to consider would be nfs_check_verifier().

Note: if you disagree with the above argument, and think that improving
that caching READDIR of results is more important, then consider the
whole discussion we had in the thread started by Tigran here:
https://lore.kernel.org/all/CAGue13pe_ZH_Eto-jL3mLjTNGFK26izTarnZdjs3eL82A2Z37w@mail.gmail.com/

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  parent reply	other threads:[~2024-02-07 14:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07 13:34 when should the client request a directory delegation? Jeff Layton
2024-02-07 14:21 ` Trond Myklebust
2024-02-07 14:56   ` Jeff Layton
2024-02-07 15:02     ` Trond Myklebust
2024-02-07 15:40       ` Jeff Layton
2024-02-07 14:56   ` Trond Myklebust [this message]
2024-02-07 15:18     ` 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=1fac8e86eae132499cc1bffe139ba397293bea9f.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rick.macklem@gmail.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;
as well as URLs for NNTP newsgroup(s).