On 2017-02-07 14:47, Kai Krakow wrote:
Am Mon, 6 Feb 2017 08:19:37 -0500
schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>:
MDRAID uses stripe selection based on latency and other measurements
(like head position). It would be nice if btrfs implemented similar
functionality. This would also be helpful for selecting a disk if
there're more disks than stripesets (for example, I have 3 disks in
my btrfs array). This could write new blocks to the most idle disk
always. I think this wasn't covered by the above mentioned patch.
Currently, selection is based only on the disk with most free
space.
You're confusing read selection and write selection. MDADM and
DM-RAID both use a load-balancing read selection algorithm that takes
latency and other factors into account. However, they use a
round-robin write selection algorithm that only cares about the
position of the block in the virtual device modulo the number of
physical devices.
Thanks for clearing that point.
As an example, say you have a 3 disk RAID10 array set up using MDADM
(this is functionally the same as a 3-disk raid1 mode BTRFS
filesystem). Every third block starting from block 0 will be on disks
1 and 2, every third block starting from block 1 will be on disks 3
and 1, and every third block starting from block 2 will be on disks 2
and 3. No latency measurements are taken, literally nothing is
factored in except the block's position in the virtual device.
I didn't know MDADM can use RAID10 on odd amounts of disks...
Nice. I'll keep that in mind. :-)
It's one of those neat features that I stumbled across by accident a
while back that not many people know about. It's kind of ironic when
you think about it too, since the MD RAID10 profile with only 2 replicas
is actually a more accurate comparison for the BTRFS raid1 profile than
the MD RAID1 profile. FWIW, it can (somewhat paradoxically) sometimes
get better read and write performance than MD RAID0 across the same
number of disks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
