|
|
Log in / Subscribe / Register

what workflow creates so many negative dentries?

what workflow creates so many negative dentries?

Posted Jul 3, 2026 16:22 UTC (Fri) by jepler (subscriber, #105975)
Parent article: Limiting negative dentries

I'm trying to imagine why this would occur with a non-pathological program. C compilers when searching an include path could create thousands, possibly... But doesn't software mostly try to open files that exist?


to post comments

what workflow creates so many negative dentries?

Posted Jul 3, 2026 18:37 UTC (Fri) by jake (editor, #205) [Link]

> I'm trying to imagine why this would occur with a non-pathological program.

It seems I failed to work in a link to a previous LSFMM+BPF session on negative dentries, which I meant to do: https://lwn.net/Articles/894098/

That has some information on workloads that end up with huge numbers of negative dentries. As do some of the links from it (and links from those links :) It is a longstanding problem as can be seen in our index entry: https://lwn.net/Kernel/Index/#Dentry_cache

jake

what workflow creates so many negative dentries?

Posted Jul 4, 2026 11:54 UTC (Sat) by mokki (subscriber, #33200) [Link]

I saw the soft lockups from negative dentries regularly 15 years ago. It was on a huge (at the time) build machine.
It just repeated endlessly: git checkout, build, rm -rf
Each round left all the files as negative dentries.
And when the system finally ran out of memory it basically locked up for minutes and would not clear most of the dentries.
I had to run a cron job in th background to flush then regularly

what workflow creates so many negative dentries?

Posted Jul 5, 2026 0:29 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> I'm trying to imagine why this would occur with a non-pathological program.

Content-addressed storage caches could do this.

what workflow creates so many negative dentries?

Posted Jul 7, 2026 3:46 UTC (Tue) by whack (subscriber, #184251) [Link]

I ran into this in production on Kubernetes. Symptoms were that pods (processes) were being evicted for no clear reason, but Kubernetes said it was due to memory pressure.

The problem? Negative dentries filling the filesystem cache!

Turns out, the blame was a health check a script for that process. It called curl every few seconds to check for health, and curl was adding 5mb to the cache (negative dentries!) every time it ran. It took a while but then suddenly poof! Process evicted due to using too much memory.

It’s a bug that still shows as open. Here’s two comments I made on it with extra details:

Report: https://github.com/kubernetes/kubernetes/issues/43916#iss...
Workaround: https://github.com/kubernetes/kubernetes/issues/43916#iss...


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds