On 2:42 10/10, Christoph Hellwig wrote: > On Tue, Oct 08, 2024 at 02:48:43AM -0700, Christoph Hellwig wrote: > > In general I'm not a huge fan of the encoded magic here, but I'll > > need to take a closer look at the caller if I can come up with > > something better. > > I looked a bit more at the code. I'm not entirely sure I fully > understand it yet, but: > > I think most of the read side special casing would be handled by > always submitting the bio at the end of an iomap. Ritesh was > looking into that for supporting ext2-like file systems that > read indirect block ondemand, but I think it actually is fundamentally > the right thing to do anyway. > > For the write we plan to add a new IOMAP_BOUNDARY flag to prevent > merges as part of the XFS RT group series, and I think this should > also solve your problems with keeping one bio per iomap? The > current patch is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=djwong-wtf&id=91b5d7a52dab63732aee451bba0db315ae9bd09b > Yes, this is helpful but it will solve only one of the three requirements. The first, compressed and uncompressed extents are to be dealth with differently because of the additional step of uncompressing the bio corresponding to the extent. So, iomap needs to inform btrfs that the bio submitted (through newly created function submit_io()) is compressed and needs to be read and decompressed. The second, btrfs sets the bi_sector to the start of the extent map and the assignment cannot go through iomap_sector(). Compressed extents being smaller than regular one, iomap_sector would most of the times overrun beyond the compressed extent. So, in this patchset, I am setting this in ->submit_io() -- Goldwyn
