On web gui I can create a RAID1 pool with 2 or more disks (in my testcase SSD’s).
While using 2 disks the available space in the pool is that of one disk (approx).
But when using 3 disks I get a free space of 1,5 disk sizes (?).
It seems that metadata are distributed.
It is described, that in this case a failure of one disk can be handled.
I’d like to have all data on all 3 disks identically, that a failure of 2 disks can be tolerated.
How can I establish a RAID1 which is “fully” mirrored?
Can it be done via terminal?
What is the mkfs commandoption to do so (if its possible at all)?
ps: I read a lot of wiki paragraphs but I did nit found this case…
According to the btrfs wiki ( https://btrfs.wiki.kernel.org/index.php/UseCases ): NOTE This does not do the ‘usual thing’ for 3 or more drives. Until “N-Way” (traditional) RAID-1 is implemented: Loss of more than one drive might crash the array. For now, RAID-1 means ‘one copy of what’s important exists on two of the drives in the array no matter how many drives there may be in it’.
… so Btrfs does not support my usecase “N-Way” … up to now.
I hope it will do it in future!
That’s about it yes. N-Way btrfs raid1 is as quoted, currently only 2 copies: one on each of 2 independent devices within a pool.
There are plans, and some proposed code in the btrfs developer community to do > 2 N-Way but they have yet to be fully reviewed and merged. So in time I fully expect this to come to fruition but it is not likely to be available any time soon. But upon it emerging I expect Rockstor to effectively ‘surface’ this soon there after.
The latest proposed code for > 2 way raid 1 from David Sterba (of SUSE and btrfs-progs maintainer) has just surfaced again on the btrfs-mailing list in the following thread:
btrfs: add support for 3-copy replication (raid1c3)
Add new block group profile to store 3 copies in a simliar way that
current RAID1 does. The profile attributes and constraints are defined
in the raid table and used by the same code that already handles the
2-copy RAID1.
The minimum number of devices is 3, the maximum number of devices/chunks
that can be lost/damaged is 2. Like RAID6 but with 33% space
utilization.
Signed-off-by: David Sterba
( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47e6f7423b9196ad6832d26cae52b7015f81ee7f )
btrfs: add support for 4-copy replication (raid1c4)
Add new block group profile to store 4 copies in a simliar way that
current RAID1 does. The profile attributes and constraints are defined
in the raid table and used by the same code that already handles the 2-
and 3-copy RAID1.
The minimum number of devices is 4, the maximum number of devices/chunks
that can be lost/damaged is 3. There is no comparable traditional RAID
level, the profile is added for future needs to accompany triple-parity
and beyond.
Signed-off-by: David Sterba
( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6fac0087e538173f34ca7431ed9b58581acf28 )
Q: Will raid1c3 and/or raid1c4 be supported by rockstor? When ;o) ?
These are still very early additions in upstream but it looks like their basic function is now starting to round out as we have the recently updated GitHub issue from December by kdave :
So hopefully as this progresses and becomes merged and more widely tested we will, in time, see it in the openSUSE btrfs back-ports that we enjoy in our ‘Built on openSUSE’ variants. There after we can look to incorporating it into our interface and back-end functions.
Just a heads up on the progress upstream on this one.