Re: Any bio_clone_slow() implementation which doesn't share bi_io_vec?

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/11/23 15:43, Christoph Hellwig wrote:
> On Tue, Nov 23, 2021 at 02:44:32PM +0800, Qu Wenruo wrote:
>> Hi,
>>
>> Although there are some out-of-date comments mentions other
>> bio_clone_*() variants, but there isn't really any other bio clone
>> variants other than __bio_clone_fast(), which shares bi_io_vec with the
>> source bio.
>>
>> This limits means we can't free the source bio before the cloned one.
>>
>> Is there any bio_clone variant which do a deep clone, including bi_io_vec?
>
> There is no use case for that, unless the actual data changes like in
> the bounce buffering code.
>
>> That's why the bio_clone thing is involved, there is still some corner
>> cases that we don't want to fail the whole large bio if there is only
>> one stripe failed (mostly for read bio, that we want to salvage as much
>> data as possible)
>>
>> Thus regular bio_split() + bio_chain() solution is not that good here.
>>
>> Any idea why no such bio_clone_slow() or bio_split_slow() provided in
>> block layer?
>>
>> Or really bio_split() + bio_chain() is the only recommended solution?
>
> You can use bio_split witout bio_chain.  You just need your own
> bi_end_io handler that first performs the action you want and then
> contains code equivalent to __bio_chain_endio.  As a bonus you can
> pint bi_private to whatever you want, it does not have to be the parent
> bio, just something that allows you to find it.
>
Without bio_chain() sounds pretty good, as we can still utilize
bi_end_io and bi_private.

But this also means, we're now responsible not to release the source bio
since it has the real bi_io_vec.

Let me explore this and hopefully to align btrfs with dm/md code more.

Thanks,
Qu