Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
	anna@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2] NFSv4: Always ask for type with READDIR
Date: Thu, 31 Aug 2023 11:24:14 -0400	[thread overview]
Message-ID: <21c3596d1ca9bbe6b73532d7b2e0c306871cf4ed.camel@kernel.org> (raw)
In-Reply-To: <6BE9526F-51FE-4CD9-AE95-EE69F7F0CAA6@redhat.com>

On Thu, 2023-08-31 at 11:17 -0400, Benjamin Coddington wrote:
> On 30 Aug 2023, at 17:14, Jeff Layton wrote:
> 
> > On Wed, 2023-08-30 at 20:20 +0000, Trond Myklebust wrote:
> > > On Wed, 2023-08-30 at 16:10 -0400, Jeff Layton wrote:
> > > > On Wed, 2023-08-30 at 15:42 -0400, Benjamin Coddington wrote:
> > > > > Again we have claimed regressions for walking a directory tree,
> > > > > this time
> > > > > with the "find" utility which always tries to optimize away asking
> > > > > for any
> > > > > attributes until it has a complete list of entries.  This behavior
> > > > > makes
> > > > > the readdir plus heuristic do the wrong thing, which causes a storm
> > > > > of
> > > > > GETATTRs to determine each entry's type in order to continue the
> > > > > walk.
> > > > > 
> > > > > For v4 add the type attribute to each READDIR request to include it
> > > > > no
> > > > > matter the heuristic.  This allows a simple `find` command to
> > > > > proceed
> > > > > quickly through a directory tree.
> > > > > 
> > > > 
> > > > The important bit here is that with v4, we can fill out d_type even
> > > > when
> > > > "plus" is false, at little cost. The downside is that non-plus
> > > > READDIR
> > > > replies will now be a bit larger on the wire. I think it's a
> > > > worthwhile
> > > > tradeoff though.
> > > 
> > > The reason why we never did it before is that for many servers, it
> > > forces them to go to the inode in order to retrieve the information.
> > > 
> > > IOW: You might as well just do readdirplus.
> > > 
> > 
> > That makes total sense, given how this code has evolved.
> > 
> > FWIW, the Linux NFS server already calls vfs_getattr for every dentry in
> > a v4 READDIR reply regardless of what the client requests. It has to in
> > order to detect junctions, so we're bringing in the inode no matter
> > what. Fetching the type is trivial, so I don't see this as costing
> > anything extra there.
> > 
> > Mileage could vary on other servers with more synthetic filesystems, but
> > one would hope that most of them can also return the type cheaply.
> 
> It occurred to me that we could let those other server folks ask for
> whatever attributes they wanted if we make it tunable at runtime:
> 
> https://lore.kernel.org/linux-nfs/8f752f70daf73016e20c49508f825e8c2c94f5e7.1693494824.git.bcodding@redhat.com/T/#u
> 

That's a possibility, but I probably wouldn't add tunables for this
until the need was more clear.
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2023-08-31 15:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 19:42 [PATCH v2] NFSv4: Always ask for type with READDIR Benjamin Coddington
2023-08-30 20:10 ` Jeff Layton
2023-08-30 20:20   ` Trond Myklebust
2023-08-30 21:14     ` Jeff Layton
2023-08-31 15:17       ` Benjamin Coddington
2023-08-31 15:24         ` Jeff Layton [this message]
2023-08-31 18:41       ` Cedric Blancher
2023-08-31 18:53         ` Jeff Layton
2023-08-31 20:08           ` Rick Macklem
2023-08-31 21:33             ` Jeff Layton
2023-09-01 16:03               ` Chuck Lever III
2023-09-07 12:43 ` Benjamin Coddington
  -- strict thread matches above, loose matches on Subject: below --
2023-12-06 13:10 Benjamin Coddington

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=21c3596d1ca9bbe6b73532d7b2e0c306871cf4ed.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=anna@kernel.org \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.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