Re: RAID56 discussion related to RST. (Was "Re: [RFC ONLY 0/8] btrfs: introduce raid-stripe-tree")

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

On 2022/7/14 15:08, Johannes Thumshirn wrote:
> On 14.07.22 03:08, Qu Wenruo wrote:> [CASE 2 CURRENT WRITE ORDER, PADDING> No difference than case 1, just when we have finished sector 7, all > zones are exhausted.>> Total written bytes: 64K> Expected written bytes: 128K (nr_data * 64K)> Efficiency:	1 / nr_data.>
> I'm sorry but I have to disagree.
> If we're writing less than 64k, everything beyond these 64k will get filled up with 0
>
>         0                               64K
> Disk 1 | D1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
> Disk 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
> Disk 3 | P | P | P | P | P | P | P | P | (Parity stripe)
>
> So the next write (the CoW) will then be:
>
>        64k                              128K
> Disk 1 | D1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
> Disk 2 | D2| 0 | 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
> Disk 3 | P'| P'| P'| P'| P'| P'| P'| P'| (Parity stripe)

Nope, currently full stripe write should still go into disk1, not disk 2.
Sorry I did use a bad example from the very beginning.

In that case, what we should have is:

        0                               64K
Disk 1 | D1| D2| 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
Disk 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | (Data stripe)
Disk 3 | P | P | 0 | 0 | 0 | 0 | 0 | 0 | (Parity stripe)

In that case, Parity should still needs two blocks.

And when Disk 1 get filled up, we have no way to write into Disk 2.

>
> For zoned we can play this game zone_size/stripe_size times, which on a typical
> SMR HDD would be:
>
> 126M/64k = 4096 times until you fill up a zone.

No difference.

You have extra zone to use, but the result is, the space efficiency will
not be better than RAID1 for the worst case.

>
> I.e. if you do stupid things you get stupid results. C'est la vie.
>

You still didn't answer the space efficient problem.

RAID56 really rely on overwrite on its P/Q stripes.
The total write amount is really twice the data writes, that's something
you can not avoid.

Thanks,
Qu