Re: [RFC PATCH] vfs: limit directory child dentry retention

[Ian Kent]

On 1/4/26 09:47, Gao Xiang wrote:
> On 2026/4/1 09:38, Ian Kent wrote:
> > On 31/3/26 17:54, Gao Xiang wrote:
> > > Hi,
> > >
> > > On 2026/3/31 17:39, Christian Brauner wrote:
> > > > On Tue, Mar 31, 2026 at 09:29:09AM +0800, Ian Kent wrote:
> > > > > If there's a very large number of children present in a directory 
> > > > > dentry
> > > > > then the benifit from retaining stale child dentries for re-use can
> > > > > become ineffective. Even hashed lookup can become ineffective as hash
> > > > > chains grow, time taken to umount a file system can increase a 
> > > > > lot, as
> > > > > well as child dentry traversals resulting in lock held too long log
> > > > > messages.
> > > >
> > > > Fwiw, there's also e6957c99dca5 ("vfs: Add a sysctl for automated 
> > > > deletion of dentry")
> > > >
> > > > This patch introduces the concept conditionally, where the associated
> > > > dentry is deleted only when the user explicitly opts for it during 
> > > > file
> > > > removal. A new sysctl fs.automated_deletion_of_dentry is added for 
> > > > this
> > > > purpose. Its default value is set to 0.
> > > >
> > > > I have no massive objections to your approach. It feels a bit hacky 
> > > > tbh
> > > > as it seems to degrade performance for new workloads in favor old
> > > > workloads. The LRU should sort this out though.
> > >
> > > JFYI, another issue we once observed on user workloads is that
> > >
> > > `d_lockref.count` can exceed `int` on very very large
> > > directories in reality (also combined with cached
> > > negative dentries).

Yeah, that's a problem for sure.

I hadn't considered such a large number of dentries so I wasn't

trying to resolve this case and I guess the change here would

only postpone the need to re-think dcache design which I suspect

is what would be needed.


Ian

> > Ouch!
> >
> > So more than 2 Billion?
>
> We received some report.
>
> > I suspect in that case you have much bigger problems than 7 or 8
> >
> > million dentries on the LRU list and linked into the directory.
>
> That shrinker seemed not to be triggered at all
> since the memory was abundant on those bare
> metals; I don't see how it cannot happen with
> enough memory and trigger negative lookups on
> a directory for example.
>
> However, it was a report quite few years ago, but
> I remembered it was a real user report
> (`d_lockref.count` overflowed).
>
> Thanks,
> Gao Xiang
>
> > > It can be a real overflow, this commit can help but it
> > > doesn't strictly resolve this, anyway.
> > >
> > > Thanks,
> > > Gao Xiang