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

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

On 2018-07-18 04:39, Duncan wrote:
> Duncan posted on Wed, 18 Jul 2018 07:20:09 +0000 as excerpted:
> 
>>> As implemented in BTRFS, raid1 doesn't have striping.
>>
>> The argument is that because there's only two copies, on multi-device
>> btrfs raid1 with 4+ devices of equal size so chunk allocations tend to
>> alternate device pairs, it's effectively striped at the macro level,
>> with the 1 GiB device-level chunks effectively being huge individual
>> device strips of 1 GiB.
>>
>> At 1 GiB strip size it doesn't have the typical performance advantage of
>> striping, but conceptually, it's equivalent to raid10 with huge 1 GiB
>> strips/chunks.
> 
> I forgot this bit...
> 
> Similarly, multi-device single is regarded by some to be conceptually
> equivalent to raid0 with really huge GiB strips/chunks.
> 
> (As you may note, "the argument is" and "regarded by some" are distancing
> phrases.  I've seen the argument made on-list, but while I understand the
> argument and agree with it to some extent, I'm still a bit uncomfortable
> with it and don't normally make it myself, this thread being a noted
> exception tho originally I simply repeated what someone else already said
> in-thread, because I too agree it's stretching things a bit.  But it does
> appear to be a useful conceptual equivalency for some, and I do see the
> similarity.
If the file is larger than the data chunk size, it _is_ striped, because 
it spans multiple chunks which are on separate devices.  Otherwise, it's 
more similar to what in GlusterFS is called a 'distributed volume'.  In 
such a Gluster volume, each file is entirely stored on one node (or you 
have a complete copy on N nodes where N is the number of replicas), with 
the selection of what node is used for the next file created being based 
on which node has the most free space.

That said, the main reason I explain single and raid1 the way I do is 
that I've found it's a much simpler way to explain generically how they 
work to people who already have storage background but may not care 
about the specifics.
> 
> Perhaps it's a case of coder's view (no code doing it that way, it's just
> a coincidental oddity conditional on equal sizes), vs. sysadmin's view
> (code or not, accidental or not, it's a reasonably accurate high-level
> description of how it ends up working most of the time with equivalent
> sized devices).)
>