Re: [PATCH 0/6] btrfs: delay compression to bbio submission time

[Qu Wenruo <wqu@suse.com>]

在 2026/4/2 09:59, Qu Wenruo 写道:
[...]
>> So
>> we are breaking the contract "OE <=> allocated space" to allow this. I
>> think making the absolute core of the improvement more apparent in the
>> descriptions would be helpful.
>>
>> I think one thing I still don't understand is the desire for the layered
>> bios/OEs instead of creating the same delayed OE, but then as we do 
>> the real
>> allocation/compression and discover the actual ranges doing
>> btrfs_split_ordered_extent() like short DIO writes, which seems quite
>> similar. Splitting/joining feels like a much more natural model for
>> ranges like OEs than layering into a tree. As we discover the sub ranges
>> we actually use, we split off the real OE.
> 
> I can definitely work towards that direction. Although my concern is the 
> OE waiting/start part and error handling.
> 
> But so far those are only concerns, I need to implement the code to see 
> what can go wrong.
> 
> And if no major problem is hit, you can see a v2 with the split solution.

Finally I recall the challenge using btrfs_split_ordered_extent(), that 
we can not split the OE in the middle.

E.g. we have a delayed OE for range [0, 32K), then due to whatever 
reasons (e.g. memory pressure), we are forced to submit range [0, 16K) 
first, then range [16K, 32K).

Both go through delayed compression, but the range [16K, 32K) win the 
race by failing the compression (bad ratio), and fallback to 
uncompressed submission first, before range [0, 16K) even finishes its 
compression.

Furthermore, for the range [16K, 32K) we do not have a large enough free 
space to fill it in one go, but can only allocate several 8K sized extents.

So we need to split the [16K, 32K) into two ranges, [16K, 24K) and [24K, 
32K).

This means we have to split the original [0, 32K) extent into [0, 16K), 
[16K, 24K) and [24K, 32K) ranges.
This is not supported by the current btrfs_split_ordered_extent(), which 
can only split range from the beginning of an OE.


I'll try to implement a version of btrfs_split_ordered_extent() that can 
split the range at any offset to see how things will work then.

Thanks,
Qu