Phillip > I had a similar question a year or two ago ( > specifically about raid10 ) so I both experimented and read the code > myself to find out. I was disappointed to find that it won't do > raid10 on 3 disks since the chunk metadata describes raid10 as a > stripe layered on top of a mirror. > > Jose's point was also a good one though; one chunk may decide to > mirror disks A and B, so a failure of A and C it could recover from, > but a different chunk could choose to mirror on disks A and C, so that > chunk would be lost if A and C fail. It would probably be nice if the > chunk allocator tried to be more deterministic about that.
I see this as a CRITICAL design flaw. The reason for calling it CRITICAL is that System Administrators have been trained for >20 years that RAID-10 can usually handle a dual-disk failure, but the BTRFS implementation has effectively ZERO chance of doing so. According to every description of RAID-10 I've ever seen (including documentation from MaxStrat), RAID-10 stripes mirrored pairs/sets of disks. The device-level description is a critical component of what makes an array "RAID-10", and is the reason for many of the attributes of RAID-10. This is NOT what BTRFS has implemented. While BTRFS may be distributing the chunks according to a RAID-10 methodology, that is NOT what the industry considers to be RAID-10. While the current methodology has the data replication of RAID-10, and it may have the performance of RAID-10, it absolutely DOES NOT have the robustness or uptime benefits that are expected of RAID-10. In order to remove this potentially catestrophic confusion, BTRFS should either call their "RAID-10" implementation something else, or they should adhere to the long-established definition of RAID-10. Peter Ashford -- 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
