On Mon, Apr 14, 2025 at 11:40:36AM -0400, James Bottomley wrote: > On Mon, 2025-04-14 at 15:30 +0100, Matthew Wilcox wrote: > > > If an application does an A:B:C directory search pattern it's > > > usually because it doesn't directly own the file location and hence > > > suggests that other applications would also be looking for it, > > > which would seem to indicate, if the search pattern gets repeated, > > > that the two negative dentries do serve a purpose. > > > > Not in this case. It's doing something like looking in /etc/app.d > > /usr/share/app/defaults/ and then /var/run/app/ . Don't quote me on > > the exact paths, or suggest alternatives based on these names; it's > > been a few years since I last looked. But I can assure you no other > > app is looking at these dentries; they're looked up exactly once. > > 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.
