On Thu, Oct 03, 2024 at 11:17:41AM +0200, Jan Kara wrote: > 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). Yeah, if we end up in evict() on ext4 it will can then do all sorts of whacky stuff that involves blocking, running transactions and doing other IO. XFS, OTOH, has been changed to defer all that crap to background threads (the xfs_inodegc infrastructure) that runs after the VFS thinks the inode is dead and destroyed. There are some benefits to having the filesystem inode exist outside the VFS inode life cycle.... > 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. I don't think the situation has improved with filesytsems like ext4. I think they've actually gotten worse - I recently learnt that ext4 inode eviction can recurse back into the inode cache to instantiate extended attribute inodes so they can be truncated to allow inode eviction to make progress. I suspect the ext4 eviction behaviour is unfixable in any reasonable time frame, so the only solution I can come up with is to run the iput() call from a background thread context. (e.g. defer it to a workqueue). That way iput_final() and eviction processing will not interfere with other writeback operations.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
