On Sat, May 11, 2024 at 11:36 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, May 10, 2024 at 07:53:49PM -0700, Linus Torvalds wrote: > > > although I think Al needs to ACK this, and I suspect that unhashing > > the dentry also makes that > > > > dentry->d_flags &= ~DCACHE_CANT_MOUNT; > > > > pointless (because the dentry won't be reused, so DCACHE_CANT_MOUNT > > just won't matter). > > > > I do worry that there are loads that actually love our current > > behavior, but maybe it's worth doing the simple unconditional "make > > d_delete() always unhash" and only worry about whether that causes > > performance problems for people who commonly create a new file in its > > place when we get such a report. > > > > IOW, the more complex thing might be to actually take other behavior > > into account (eg "do we have so many negative dentries that we really > > don't want to create new ones"). > > > > Al - can you please step in and tell us what else I've missed, and why > > my suggested version of the patch is also broken garbage? > > Need to RTFS and think for a while; I think it should be OK, but I'll need > to dig through the tree to tell if there's anything nasty for e.g. network > filesystems. > > Said that, I seriously suspect that there are loads where it would become > painful. unlink() + creat() is _not_ a rare sequence, and this would > shove an extra negative lookup into each of those. > > I would like to see the details on original posters' setup. Note that > successful rmdir() evicts all children, so that it would seem that their > arseloads of negative dentries come from a bunch of unlinks in surviving > directories. Right, the directories are fixed. We've engaged in discussions with ES users regarding changing the directory, but it would entail a significant adjustment for them. > > It would be interesting to see if using something like > mkdir graveyard > rename victim over there, then unlink in new place > rename next victim over there, then unlink in new place > .... > rmdir graveyard > would change the situation with memory pressure - it would trigger > eviction of all those negatives at controlled point(s) (rmdir). > I'm not saying that it's a good mitigation, but it would get more > details on that memory pressure. -- Regards Yafang
