Re: bad things when too many negative dentries in a directory

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2025-04-14 at 17:14 +0100, Matthew Wilcox wrote:
[...]
> > I got that's what it's doing, and why the negative dentries are
> > useless since the file name is app specific, I'm just curious why
> > an app that knows it's the only consumer of a file places it in the
> > last place it looks rather than the first ... it seems to be
> > suboptimal and difficult for us to detect heuristically.
> 
> The first two are read only.  One is where the package could have an
> override, the second is where the local sysadmin could have an
> override. The third is writable.  It's not entirely insane.
> 
> Another way to solve this would be to notice "hey, this directory
> only has three entries and umpteen negative entries, let's do the
> thing that ramfs does to tell the dcache that it knows about all
> positive entries in this directory and delete all the negative
> ones".  I forget what flag that is.

It's not a flag, it's the dentry operations for pseudo filesystems
(simple_lookup sets simple_dentry_operations which provides a d_delete
that always says don't retain).  However, that's really because all
pseudo filesystems have a complete dentry cache (all visible files have
dentries), so there's no benefit caching negative lookups (and the
d_delete trick only affects negative dentries because positive ones
have a non zero refcount).

There is a DCACHE_DONTCACHE flag that dumps a dentry (regardless of
positive or negative) on final dput  I suppose that could be set in
lookup_open() on negative under some circumstances (open flag, sysctl,
etc.).

Regards,

James