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

I've just noticed that I'm not sure about your mindset of this raid5/6
rst feature.
So I want to know do you think the raid5/6 rst is extent layer raid or
block layer raid?
Because they are quite different and I need to align it with you
before further discussion.

For extent layer raid5/6, it's more like what zfs is doing now: we do
the "raid" thing on each
file extent, split big extent into stripes, and write them on
different disks with parity. The issue
of this is that the performance and efficiency on small extents is
bad, but we can always
do full stripe write, avoiding write hole issues.

For block layer raid5/6, which is like what we currently have without
rst, we need to deal with the
write hole issue, possibly by
1. totally avoid read-modify-write for a partial stripe update. We
always write into a new stripe
  append only instead of modifying an existing stripe, like writing a
zoned device even on non-zoned device.
2. or we allow read-modify-write for a partial stripe update, but
write the D and P elsewhere
  instead of in-place.

Option 2 will cause another free space management issue I've mentioned before:
let's take a 4 disk raid 5 as example.
before the partial stripe update, logical address LA is mapped to
physical address PA0(D0), PA1(D1), PA2(D2), PA3(P);
after updating D2, LA is mapped to address PA0(D0), PA1(D1), PA2'(D2'), PA3'(P')
then we need to allocate PA2' and PA3' , and free PA2 and PA3 on disk 2 and 3.
Since currently btrfs manage freespace based on logical address, how
to manage the allocation and manage physical free space?


On Mon, Jun 22, 2026 at 6:23 PM Johannes Thumshirn
<[email protected]> wrote:
>
> 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.