Re: [RFC 00/15] btrfs: RAID5 with RAID stripe-tree (zoned + non-zoned)

On 6/19/26 3:28 PM, sun k wrote:
> Hi Johannes,
>
> Glad to know that you're working on btrfs's raid56 and raid stripe tree.
> This really a big change and it will really take me quite some time to
> dive into the code implementation.
>
> Before going into code details, I take a glance on the total design and
> it seems nice for me. But there's still some details that I'm currently
> not sure so please correct me if I got anything wrong.
>
> First is about partial update. With this RFC they'll not updated
> in-place(overwrite) anymore, but use a cow method instead, which means
> ... we'll write that data elsewhere on disk, but still share the
> previous logical address? This will change address mapping for a
> blockgroup while current existing blockgroup profiles will not change
> the address mapping in their entire lifetime IIRC so I have no idea if
> current free space management things can works with this.

I'm not sure I follow here. This is how the RAID stripe tree works, it 
maps logical to device physical addresses.

>
> Second is about the new key type in raid stripe tree. It makes the tree
> search more complex as we've discussed before. So I wonder if it will
> work just putting the parity stripe into RAID_STRIPE_KEY item, and using
> the last 1 stripe for parity on raid5, the last 2 on raid6.

Theoretically yes, but who's guaranteeing the order of IO completions 
that trigger the tree item insert? So that means we have to build the 
stripe extent upfront, then submit the IO and then update and send the 
stripe extent once all data and parity writes are done. Otherwise we 
can't use zone append on a zoned FS.


> Third is about the partial tail. If we have 4 disks for raid 5 setup,
> and the extent only fills one and a half stripe, how will things work in
> this RFC? And why use file size to decide it is a genuine tail? I have
> no idea why it makes sense.


The file size is purely an optimization. If we complete an OE and we're 
at isize, we know it's the last extent regardless if it's partial or not.

> BTW, this might be a little off-topic but I've just read closure.h
> recently and I wonder if we could use that to make bio related things
> more readable and easier to work with in btrfs.
I'd need to look into this, its been a long time since I've looked into it.