Re: [PATCH 0/2] btrfs: introduce a new experimental feature, RAID56_VSL

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

在 2026/9/3 22:03, Johannes Thumshirn 写道:
> On 9/3/26 8:49 AM, Qu Wenruo wrote:
>> The new feature stands for RAID56 Variable Stripe Length, however the
>> VSL part is not implemented yet, thus the whole feature is still hidden
>> behind experimental, and there are definitely works left to properly
>> split the 1st patch.
>>
>> But for now, this series can pass most fstests cases.
>> The failing ones are all related to mixed block groups, which can not be
>> created nor mounted with this new feature.
> 
> Why not make mixed incompatible with it then?

It's already rejected by kernel.

And for progs (and I noticed I forgot to send the patch) it will reject 
mkfs.

> 
>>
>> The roadmap for the full RAID56 VSL implementation is split into two
>> parts:
>>
>> - Introduce a new datasize member
>>    This series.
>>
>>    An fs with data_size 8K and sectorsize 4K will act like a fs with
>>    sectorsize 8K.
>>    Meaning the minimal write size is 8K for data.
>>
>>    However the checksum is still calculated based sectorsize, meanwhile
>>    we can still recover each corrupted 4K sector inside a 8K data block.
>>
>>    The idea and implementation is not that complex, we're just reusing
>>    the existing bs > ps support to handle it (on 4K page sized systems).
>>
>>    But the challenge is the details where some part of the code still
>>    requires sectorsize (checksum related), meanwhile every other location
>>    goes datasize for data.
>>
>> - Introduce a new RAID56_VSL chunk type
>>    It will have the following requirements:
>>
>>    * Can have up to (datasize / sectorsize) data stripes
>>
>>    * The number of data stripes are always power of 2
>>      This is only for every RAID56_VSL chunk, users can still have
>>      whatever number of devices in the fs.
>>
>>    * The full stripe length is always datasize
>>
>>    This allows every data write to be full stripe aligned.
>>    And for read repair/scrub, we can still locate and recover a single
>>    sector inside a RAID56 stripe.
>>
>>    This is less flex than the traditional RAID56, which has no limit on
>>    the number of data stripes, but has the write-hole problem.
>>    And will require users to determine the maximum device numbers at mkfs
>>    time, without any way to change to another datasize.
>>
>>    But the second part is pretty easy to implement.
>>
>> As the digest shows, the biggest problem is the first patch, which is
>> touching over 200 sectorsize users, and is definitely the source of all
>> bugs I hit and fixed so far.
> 
> 
> But this is still all !zoned RAID56, isn't it? Or did I miss something?

Yes, all for non-zoned RAID56.