On 10/29/2025 2:25 PM, Christoph Hellwig wrote: > On Tue, Oct 28, 2025 at 11:09:32PM -0700, Darrick J. Wong wrote: >> Was that with or without rtgroups? metadir/rtgroups aren't enabled by >> default yet so you'd have to select that manually with mkfs.xfs -m >> metadir=1. >> >> (and you might still not see much change because of what hch said) > > The real problem here is that even the inode number to AG association > is just a hint, and will often go wrong on an aged file system. > > Now for the zoned RT device we could probably do a thread per open > zone, as that is a very logical association. The problem with that > right now is that we only pick the zone to write to once doing > writeback, but there might be ways to lift it up. Then again > zoned writeback is so little code that I can't see how it would > saturate a single thread. >
Predicting the Allocation Group (AG) for aged filesystems and passing this information to per-AG writeback threads appears to be a complex task. For write operations without pre-allocated data blocks (fallocate=none, resulting in DELALLOC), the next available AG is selected, and the XFS hook can be used to predict the AG that will be allocated. In contrast, when writing to a previously allocated data block (fallocate default, resulting in UNWRITTEN), the AG containing the data block is chosen. Large files that span multiple AGs can lead to a mix of random I/O operations (DELALLOC, UNWRITTEN, MAPPED) being directed to different AGs, while still being cached in the same page cache. To segregate these I/O requests by AG, it is necessary to associate AG-specific information with the pages/folios in the page cache. Two possible approaches are: (1) storing AG information in the folio->private field, or (2) introducing new markers in the xarray to track AG-specific data. The AG-affined writeback thread processes specific pages from the page cache marked for its AG. Is this a viable approach, or are there alternative solutions that could be more effective? >> >> --D > ---end quoted text--- > _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
