On 2022/3/23 14:17, Christoph Hellwig wrote:
On Wed, Mar 23, 2022 at 09:39:24AM +0800, Qu Wenruo wrote:
Not familar with iomap thus I can be totally wrong, but isn't the idea
of iomap to separate more code from fs?
Well, to share more code, which requires a certain abstraction, yes.
I'm really not sure if it's a good idea to expose btrfs internal bio_set
just for iomap.
We don't. iomap still purely operates on the generic bio. It just
allocates additional space for btrfs to use after ->submit_io is called.
Just like how e.g. VFS inodes can come with extra space for file
system use.
OK, it's just higher layer pre-allocates those structures.
A little curious if there will be other users of this other than btrfs.
I guess for XFS/EXT4 they don't need any extra space and can just submit
the generic bio directly to their devices?
Personally speaking I didn't see much problem of cloning an iomap bio,
it only causes extra memory of btrfs_bio, which is pretty small previously.
It is yet another pointless memory allocation in something considered very
much a fast path.
Another concern is, this behavior mostly means we don't split the
generic bio.
Or we still need to allocate memory for the btrfs specific memory for
the new bio.
Thanks,
Qu
