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. 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.
