Re: [PATCH v4 0/9] btrfs: compression: refactor and enhancement preparing for subpage compression support

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

On 2021/6/18 上午12:47, David Sterba wrote:
> On Thu, Jun 17, 2021 at 01:14:41PM +0800, Qu Wenruo wrote:
>> There are quite some problems in compression code:
>>
>> - Weird compressed_bio::pending_bios dance
>>    If we just don't want compressed_bio being freed halfway, we have more
>>    sane methods, just like btrfs_subpage::readers.
>>
>>    So here we fix it by introducing compressed_bio::io_sectors to do the
>>    job.
>>
>> - BUG_ON()s inside btrfs_submit_compressed_*()
>>    Even they are just ENOMEM, we should handle them.
>>    With io_sectors introduced, we have a way to finish compressed_bio
>>    all by ourselves, as long as we haven't submitted last bio.
>>
>>    If we have last bio submitted, then endio will handle it well.
>>
>> - Duplicated code for compressed bio allocation and submission
>>    Just small refactor can handle it
>>
>> - Stripe boundary is checked every time one page is added
>>    This is overkilled.
>>    Just learn from extent_io.c refactor which use bio_ctrl to do the
>>    boundary check only once for each bio.
>>
>>    Although in compression context, we don't need extra checks in
>>    extent_io.c, thus we don't need bio_ctrl structure, but
>>    can afford to do it locally.
>>
>> - Dead code removal
>>    One dead comment and a new zombie function,
>>    btrfs_bio_fits_in_stripe(), can be removed now.
>
> I went through it several times, the changes are scary, but the overall
> direction is IMHO the right one, not to say it's fixing the difficult
> BUG_ONs.
>
> I'll put it to for-next once it passes a few rounds of fstests. Taking
> it to 5.14 could be risky if we don't have enough review and testing,
> time is almost up before the code freeze.
>
Please don't put it into 5.14.

It's really a preparation for subpage compression support.
However we don't even have subpage queued for v5.14, thus I'm not in a
hurry.

Thanks,
Qu