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).)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
