In the first paragraph it describes something I hadn’t seen before and can’t seem to find anything authoritative.
I don’t know how reliable what I read on Reddit might be, from that it describes…
RAID1C is typically followed by a number which describes the number of mirrored disks. In other words a standard RAID1 only mirrors one disk to another but something like RAID1C2 might mean that data is mirrored to 2 disks, not just one.
If this is true, then this is supposedly to address the BTRFS issue supporting large arrays where the parity bit can be corrupted. Mirroring doesn’t utilize a parity bit, and would support replicating data to as many mirrors as one might wish. It’s not the same as RAID5/6, but it is an interesting different approach to disk fault tolerance.
This is apparently something very new so people should be careful about this new technology, but it has promise particularly if it’s an iteration of widely used and reliable technology and not a major leap into the unknown.
In any case, even if it’s newly available in the latest TW and possibly 15.2 kernels, documentation will need to be available if not guides and blogging before anyone could know how to set up and maintain (unless it just suddenly shows up in the BTRFS RAID management).
Just for reference,
I collected some good links for anyone who wants to implement BTRFS RAID (and BTRFS in general) in my openSUSE Wiki
Thx Malcolm,
That’s something although still very cryptic…
From the second link,
**btrfs: Add support for new RAID1C34 profiles
**New 3- and 4-copy variants of RAID1 were merged into Linux kernel 5.5.Add the two new profiles to the list of recognized ones. As this buildson the same code as RAID1, only the redundancy level needs to beadjusted, the rest is done by the existing code.Signed-off-by: David Sterba <dsterba@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
From that,
Assuming that the “copies” do not include the original, then BTRFS RAID should now support 2,4 and 5 disks.
Although I can understand a 4 disk array which is very popular and a 5 disk array which is not uncommon I’m now wondering if there is a reason to exclude a 3 disk and 6 or more disk arrays. I suspect that if the code is written as well as I hope and in a way I mentally theorize the number of mirrored copies should not be practically limited(maybe 256 disks?). I suspect that the limitation may be more due to using fixed labels for GRUB rather than programmatically creating a GRUB label and passing the numeric value to specify the number of disks in the array.
To the casual reader, note though that this new mirroring doesn’t really substitute for RAID 5 or 6. Whereas RAID 5 or 6 uses only the equivalence of one disk for redundancy/parity and the rest for original data, any type of RAID1 will only be one disk of data and all the other disks in the array will be copies. That’s very different in numerous ways.
I wonder if the GRUB limitation also applies to creating BTRFS RAID from the command line. I suspect not. It’ll be interesting to see what would actually see when creating a BTRFS RAID. It’ll also be interesting why a GRUB entry is even desirable or needed unless someone would want an option to not boot to a specified RAID level. Maybe there is something I’ve missed, but I wasn’t aware that even in current BTRFS RAID that the GRUB entry calls out the RAID configuration, I had thought that GRUB merely points to boot files where such things would be configured and implemented.
Lots of provocative thoughts.
Will be awhile until I have a machine ready to test these in either a virtual or physical setup, though…
Maybe anyone else that is curious will beat me to it.
