Re: [PATCH 0/4] 3- and 4- copy RAID1

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2018-07-16 14:29, Goffredo Baroncelli wrote:
> On 07/15/2018 04:37 PM, waxhead wrote:
>> David Sterba wrote:
>>> An interesting question is the naming of the extended profiles. I picked
>>> something that can be easily understood but it's not a final proposal.
>>> Years ago, Hugo proposed a naming scheme that described the
>>> non-standard raid varieties of the btrfs flavor:
>>>
>>> https://marc.info/?l=linux-btrfs&m=136286324417767
>>>
>>> Switching to this naming would be a good addition to the extended raid.
>>>
>> As just a humble BTRFS user I agree and really think it is about time to move far away from the RAID terminology. However adding some more descriptive profile names (or at least some aliases) would be much better for the commoners (such as myself).
>>
>> For example:
>>
>> Old format / New Format / My suggested alias
>> SINGLE  / 1C     / SINGLE
>> DUP     / 2CD    / DUP (or even MIRRORLOCAL1)
>> RAID0   / 1CmS   / STRIPE
> 
> 
>> RAID1   / 2C     / MIRROR1
>> RAID1c3 / 3C     / MIRROR2
>> RAID1c4 / 4C     / MIRROR3
>> RAID10  / 2CmS   / STRIPE.MIRROR1
> 
> Striping and mirroring/pairing are orthogonal properties; mirror and parity are mutually exclusive. What about
> 
> RAID1 -> MIRROR1
> RAID10 -> MIRROR1S
> RAID1c3 -> MIRROR2
> RAID1c3+striping -> MIRROR2S
> 
> and so on...
> 
>> RAID5   / 1CmS1P / STRIPE.PARITY1
>> RAID6   / 1CmS2P / STRIPE.PARITY2
> 
> To me these should be called something like
> 
> RAID5 -> PARITY1S
> RAID6 -> PARITY2S
> 
> The S final is due to the fact that usually RAID5/6 spread the data on all available disks
> 
> Question #1: for "parity" profiles, does make sense to limit the maximum disks number where the data may be spread ? If the answer is not, we could omit the last S. IMHO it should.
Currently, there is no ability to cap the number of disks that striping 
can happen across.  Ideally, that will change in the future, in which 
case not only the S will be needed, but also a number indicating how 
wide the stripe is.

> Question #2: historically RAID10 is requires 4 disks. However I am guessing if the stripe could be done on a different number of disks: What about RAID1+Striping on 3 (or 5 disks) ? The key of striping is that every 64k, the data are stored on a different disk....
This is what MD and LVM RAID10 do.  They work somewhat differently from 
what BTRFS calls raid10 (actually, what we currently call raid1 works 
almost identically to MD and LVM RAID10 when more than 3 disks are 
involved, except that the chunk size is 1G or larger).  Short of drastic 
internal changes to how that profile works, this isn't likely to happen.

In spite of both of these, there is practical need for indicating the 
stripe width.  Depending on the configuration of the underlying storage, 
it's fully possible (and sometimes even certain) that you will see 
chunks with differing stripe widths, so properly reporting the stripe 
width (in devices, not bytes) is useful for monitoring purposes).

Consider for example a 6-device array using what's currently called a 
raid10 profile where 2 of the disks are smaller than the other four.  On 
such an array, chunks will span all six disks (resulting in 2 copies 
striped across 3 disks each) until those two smaller disks are full, at 
which point new chunks will span only the remaining four disks 
(resulting in 2 copies striped across 2 disks each).