Re: NFS delegations behavior analysis

On Tue, 2026-06-23 at 09:11 -0400, Benjamin Coddington wrote:
> On 23 Jun 2026, at 7:10, Jeff Layton wrote:
> 
> > I think Ben did the latest pass of trying to tune the heuristics here.
> > Any thoughts on how we could do this better (and whether there are
> > particular ls-ish workloads that we don't want to regress)?
> 
> I haven't (shame) thought about READDIR in the context of directory
> delegations.
> 
> But during my time at Red Hat we worked hard to optimize some readdir
> problems and I learned that almost any change we made ended up making
> someone's workload regress.  We also found that our performance benchmarks
> rarely matched the most common real-world workloads.  We made the mistake of
> trying to improve the benchmark which resulted in performance regressions
> for real-world users.
> 
> Jeff, you've already touched on the core issue regarding fixing this with
> bulk GETATTR calls - the kernel doesn't know what syscall pattern the
> userspace process is going to use next.  The `ls -l` command and `find` and
> friends have complex history and branching logic, they do different lookup
> and getattr patterns based on their own goals, and NFS cannot optimize for
> any one case.
> 
> I think the last time we discussed additional improvements there were some
> ideas about teaching the readdir code to respond to fadvise flags, but then
> you'd also need to teach the utilities how to use them as well, and those
> utilities try to be filesystem-agnostic.
> 
> Its a tough problem, and sometimes the simplest thing might be to just use
> more directories on NFS.
> 
> **coffee!**
> 
> .... er - so with directory delegations, can we simply re-hydrate the dentry
> cache from the directory page mappings if the delegation is still valid?
> Does the directory delegation pin the mapping?  Clearly I need to look at
> the code..
> 

I think the main problem is not the dcache, but the attributes on the
inodes. The first pass uses a full-attrs READDIR (aka readdirplus) and
everything goes reasonably quick.

Then, on the second pass, the client skips checking directory
attributes before trusting the dcache because of the delegation (which
is good), but the inodes those dentries point to have an attrcache
timeout, and we end up doing a GETATTR for each statx() call when a
readdirplus would have been cheaper.

I guess after you see a few statx() calls from the same pid on the same
directory in a short timeframe you could switch to doing READDIR, but
that sounds horrid to get right and keep working.

-- 
Jeff Layton <[email protected]>