On 11/4/25 23:40, Miklos Szeredi wrote:
On Fri, 11 Apr 2025 at 16:47, Christian Brauner <brauner@xxxxxxxxxx> wrote:
Note that we have a new sysctl:
/proc/sys/fs/dentry-negative
that can be used to control the negative dentry policy because any
generic change that we tried to make has always resulted in unacceptable
regressions for someone's workload. Currently we only allow it to be set
to 1 (default 0). If set to 1 it will not create negative dentries
during unlink. If that's sufficient than recommend this to users that
suffer from this problem if not consider adding another sensitive
policy.
Okay, I'll forward that info.
However, hundreds of millions of negative dentries can be created
rather efficiently without unlink, though this one probably doesn't
happen under normal circumstances. Allowing this to starve the
scheduler for an arbitrary long time is not a good idea in any case,
so the fsnotify problem needs some other solution, and I suspect that
it's not to disable negative caching completely, as that would be a
major bummer.
I know that the most recent case we have seen of this would probably
be resolved by the sysctl but this was not the first recent case we had.
Unfortunately I can't remember the details, all I remember is it was
similar but not quite the same.
In any case it's quite possible that many files can be processed, opened
and then closed, not unlinked.
So I think it's worth considering this as well.
But the idea of leaving negative dentries off d_children is
independent of caching policy. The lookup cache would work fine
without d_sib being chained, it only needs careful thought in
1) putting the dentry on d_children when it's turned into positive
2) getting the dentry off d_children when it's turned into negative.
That shouldn't be too difficult to do ... sounds like a good idea to me.
Ian
