On 2022/3/23 16:11, Christoph Hellwig wrote:
On Wed, Mar 23, 2022 at 04:02:34PM +0800, Qu Wenruo wrote:
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?
For normal I/O, yes. But if we want to use Zone Append we'll basically
need to use this kind of hook everywhere.
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.
With the current series we never split it, yes. I'm relatively new
to btrfs, so why would we want to split the bio anyway?
Two reasons, one is to make iomap call backs easier, they won't need to
bother the stripe boundary anymore if we can do the bio split inside btrfs.
(Also why I want to get rid of the zone boundary check, but not any clue
on that yet)
Another one is purely design pattern.
We want better layer separation, things like stripe boundary should
belong to chunk layer, thus split should also happen when we map the
bio, not the read/write path.
This is exactly how the stack drivers do, and I really hope to follow
the path.
As far as I can tell this is only done for parity raid, and maybe
we could actually do the split for those with just this scheme.
I.e. do what you are doing in your series in btrfs_map_bio and
allow to clone partial bios there, which should still be possible
threre.
I guess yes, we are probably still able to do that.
Just to mention we can not really get rid of the memory allocation.
We'd still need the high-level btrfs_bio to contain the
mapping and various end I/O infrastructure like the btrfs_work.
Then it looks fine to me now.
Thanks,
Qu
