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
