Re: [PATCH 40/40] btrfs: use the iomap direct I/O bio directly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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.  We'd still need the high-level btrfs_bio to contain the
mapping and various end I/O infrastructure like the btrfs_work.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux