On Mon, 2025-04-14 at 15:30 +0100, Matthew Wilcox wrote: > On Mon, Apr 14, 2025 at 10:07:09AM -0400, James Bottomley wrote: > > On Fri, 2025-04-11 at 17:01 +0100, Matthew Wilcox wrote: > > > On Fri, Apr 11, 2025 at 05:40:08PM +0200, Miklos Szeredi wrote: > > > > However, hundreds of millions of negative dentries can be > > > > created rather efficiently without unlink, though this one > > > > probably doesn't happen under normal circumstances. > > > > > > Depends on your userspace. Since we don't have union > > > directories, consider the not uncommon case of having a search > > > path A:B:C. Application looks for D in directory A, doesn't find > > > it, creates a negative dentry. Application looks for D in > > > directory B, creates a negative dentry. Application looks for D > > > in directory C, doesn't find it, so it creates it. Now we have > > > two negative dentries and one positive dentry. > > > > 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. Regards, James
