From: Ian Kent <raven@themaw.net>
To: Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Cc: Ian Kent <raven@themaw.net>, Miklos Szeredi <miklos@szeredi.hu>,
Eric Sandeen <sandeen@sandeen.net>,
Frank Sorenson <fsorenso@redhat.com>,
Jay Shin <jaeshin@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Yafang Shao <laoar.shao@gmail.com>, Jan Kara <jack@suse.cz>,
Waiman Long <longman@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Wangkai <wangkai86@huawei.com>,
Colin Walters <walters@verbum.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH] Limit directory child dentry retention
Date: Tue, 31 Mar 2026 09:29:08 +0800 [thread overview]
Message-ID: <20260331012925.74840-1-raven@themaw.net> (raw)
Hi all,
Please forgive the long description but this seems to be a long standing
problem so I'd like to offer a suggestion for improvenment (but probably
not a complete solution).
I have seen a problem where, in one case, a directory has around 12M
children with about 80% of them negative. Then an fsnotify function is
called that needs to traverse the entire list of directory children
while holding the inode i_lock with obvious consequences.
Some time ago commit 681ce8623567 ("vfs: Delete the associated dentry
when deleting a file") was merged to try and solve excessive accumulation
of negative dentries. It was later Reverted in Commit 4a4be1ad3a6e due to
performance regressions. In addition commit 172e422ffea2 ("fsnotify: clear
PARENT_WATCHED flags lazily" was suggested as a fix but one of the reports
we have triggeres the problem via fsnotify_add_mark_locked() which still
traverses the entire child list after commit 172e422ffea2 is applied.
Having worked though the above commits (and the revert) it occured to me
that a similarly simple approach would be to only limit directory dentry
retention when some highwater level was reached. A kind of keep a bunch
of negative dentries to try not to interfere with the dcache but discard
them on last dput if there are so many child dentries that the benifit
of caching them would likely be negated. TBH I don't know what that
highwater value should be so that's one thing to be worked out.
I don't have a reproducer but I presume the people I've included on the
cc list may have some tests. TBH I don't see how Commit 681ce8623567
caused a regression since that should have required a re-create (probably
many) for the same file to cause it. Nevertheless the patch here is yet
another a very simple approach to helping with the stale directory dentry
accumulation problem we see all too often.
Thoughts and comments please.
Ian Kent (1):
vfs: limit directory child dentry retention
Documentation/admin-guide/sysctl/fs.rst | 7 +++++++
fs/dcache.c | 28 +++++++++++++++++++++++++
2 files changed, 35 insertions(+)
--
2.53.0
next reply other threads:[~2026-03-31 1:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 1:29 Ian Kent [this message]
2026-03-31 1:29 ` [RFC PATCH] vfs: limit " Ian Kent
2026-03-31 9:39 ` Christian Brauner
2026-03-31 9:54 ` Gao Xiang
2026-03-31 14:59 ` Mateusz Guzik
2026-03-31 15:11 ` Gao Xiang
2026-04-01 1:38 ` Ian Kent
2026-04-01 1:47 ` Gao Xiang
2026-04-01 2:21 ` Ian Kent
2026-04-01 2:40 ` Linus Torvalds
2026-04-01 2:10 ` Ian Kent
2026-04-07 10:35 ` Christian Brauner
2026-04-07 12:41 ` Ian Kent
2026-04-08 10:17 ` Jan Kara
2026-04-09 0:59 ` Ian Kent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260331012925.74840-1-raven@themaw.net \
--to=raven@themaw.net \
--cc=brauner@kernel.org \
--cc=fsorenso@redhat.com \
--cc=jack@suse.cz \
--cc=jaeshin@redhat.com \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=miklos@szeredi.hu \
--cc=sandeen@sandeen.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walters@verbum.org \
--cc=wangkai86@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®