On Thu 03-10-24 11:41:42, Dave Chinner wrote: > On Wed, Oct 02, 2024 at 07:20:16PM -0400, Kent Overstreet wrote: > > A couple things that help - we've already determined that the inode LRU > > can go away for most filesystems, > > We haven't determined that yet. I *think* it is possible, but there > is a really nasty inode LRU dependencies that has been driven deep > down into the mm page cache writeback code. We have to fix that > awful layering violation before we can get rid of the inode LRU. > > I *think* we can do it by requiring dirty inodes to hold an explicit > inode reference, thereby keeping the inode pinned in memory whilst > it is being tracked for writeback. That would also get rid of the > nasty hacks needed in evict() to wait on writeback to complete on > unreferenced inodes. > > However, this isn't simple to do, and so getting rid of the inode > LRU is not going to happen in the near term. Yeah. I agree the way how writeback protects from inode eviction is not the prettiest one but the problem with writeback holding normal inode reference is that then flush worker for the device can end up deleting unlinked inodes which was causing writeback stalls and generally unexpected lock ordering issues for some filesystems (already forgot the details). Now this was more that 12 years ago so maybe we could find a better solution to those problems these days (e.g. interactions between page writeback and page reclaim are very different these days) but I just wanted to warn there may be nasty surprises there. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
