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

[Ian Kent <raven@themaw.net>]

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
>