On Thu, Nov 23, 2023 at 09:26:44AM +1100, Dave Chinner wrote: > On Wed, Nov 22, 2023 at 05:11:18AM -0800, Christoph Hellwig wrote: > > On Wed, Nov 22, 2023 at 01:29:46PM +0100, Jan Kara wrote: > > > writeback bit set. XFS plays the revalidation sequence counter games > > > because of this so we'd have to do something similar for ext2. Not that I'd > > > care as much about ext2 writeback performance but it should not be that > > > hard and we'll definitely need some similar solution for ext4 anyway. Can > > > you give that a try (as a followup "performance improvement" patch). > > > > Darrick has mentioned that he is looking into lifting more of the > > validation sequence counter validation into iomap. > > I think that was me, as part of aligning the writeback path with > the ->iomap_valid() checks in the write path after we lock the folio > we instantiated for the write. > > It's basically the same thing - once we have a locked folio, we have > to check that the cached iomap is still valid before we use it for > anything. > > I need to find the time to get back to that, though. Heh, we probably both have been chatting with willy on and off about iomap. The particular idea I had is to add a u64 counter to address_space that we can bump in the same places where we bump xfs_inode_fork::if_seq right now.. ->iomap_begin would sample this address_space::i_mappingseq counter (with locks held), and now buffered writes and writeback can check iomap::mappingseq == address_space::i_mappingseq to decide if it's time to revalidate. Anyway, I'll have time to go play with that (and further purging of function pointers) next week or whenever is "after I put out v28 of online repair". ATM I have a rewrite of log intent recovery cooking too, but that's going to need at least a week or two of recoveryloop testing before I put that on the list. --D > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
