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

[Ian Kent]

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).

Ouch!

So more than 2 Billion?

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.


> It can be a real overflow, this commit can help but it
> doesn't strictly resolve this, anyway.
>
> Thanks,
> Gao Xiang