On Thu 30-11-23 13:15:58, Ritesh Harjani wrote: > Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> writes: > > > Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> writes: > > > >> Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: > >> > >>> 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). > > ok. So I am re-thinknig over this on why will a filesystem like ext2 > would require sequence counter check. We don't have collapse range > or COW sort of operations, it is only the truncate which can race, > but that should be taken care by folio_lock. And even if the partial > truncate happens on a folio, since the logical to physical block mapping > never changes, it should not matter if the writeback wrote data to a > cached entry, right? Yes, so this is what I think I've already mentioned. As long as we map just the block at the current offset (or a block under currently locked folio), we are fine and we don't need any kind of sequence counter. But as soon as we start caching any kind of mapping in iomap_writepage_ctx we need a way to protect from races with truncate. So something like the sequence counter. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
