On the CLI:
(Use drives that have been wiped in the GUI. Device names below are examples only.)
mkfs.btrfs -f -d raid5 /dev/sdb /dev/sdc /dev/sdd (If you want to look over the options for the above, a reference is -> here.)
btrfs filesystem label /dev/sdb BTRFS1 (Where BTRFS1 is the name of the array, substitute your name in.)
Go in the GUI;
Storage, File Systems, and the new BTRFS array will be there. Mount it.
Done.
________________________________
Of course there's much more involved in maintaining the array and configuring features like sub-volumes. Most of this must be done on the CLI, but the above is a start.
Edit:
Note the following is not an opinion; it came from a warning on the command line and is contained in dmesg .
Obviously, backup is recommended.
mkfs.btrfs -f -d raid5 /dev/sdb /dev/sdc /dev/sdd
BS advice as almost always. I explained to you (flmaxey) and others already over at 'this thread' that adding -m raid1 is the way to go since this will protect metadata or 'the filesystem itself'. You should really start to learn at least the basics.
Tkaiser,but isnt this default state:
By default, metadata will be mirrored across two devices and data will be striped across all of the devices present. This is equivalent to mkfs.btrfs -m raid1 -d raid0.
https://btrfs.wiki.kernel.org/…rfs_with_Multiple_Devices
BS advice as almost always. I explained to you (flmaxey) and others already over at 'this thread' that adding -m raid1
You explain next to nothing to me because, as I've told you numerous times (and will yet again), I ignore you. 
Considering what I've observed (a decidedly dual nature), you might try it some time.
_________________________________________________________
Since you forced this thread into a PM to get it done, you didn't learn the specifics of what the user was trying to do. (As if that would have made any difference.) Primary storage is to be on RAID5/6 array, or a COW equivalent. Since @savellm is in a test build phase, he wanted to look at the BTRFS possibility. That's it, short and simple.
So, the above was not bad advice - just a demo. It just underscores certain realities of trying to using a filesystem (BTRFS) for RAID5/6, that's not ready. The warning is pretty clear. One might wonder why they put that in there.....
By default, metadata will be mirrored across two devices and data will be striped across all of the devices present. This is equivalent to mkfs.btrfs -m raid1 -d raid0.
btrfs.wiki.kernel.org/index.ph…rfs_with_Multiple_Devices
Nope, that's about btrfs behavior with multiple devices without RAID. I linked to https://github.com/openmediava…01#issuecomment-467000104 above for a reason. Since there everything is explained by a kernel developer in the link provided there: https://www.mail-archive.com/linux-<woltlab-metacode-marker data-name="email" data-uuid="5355616e-af83-44fa-972f-cf350f74d101" data-source="W2VtYWlsXQ==" data-attributes="WyJidHJmc0B2Z2VyLmtlcm5lbC5vcmciXQ==" data-use-text="0" /><woltlab-metacode-marker data-uuid="5355616e-af83-44fa-972f-cf350f74d101" data-source="Wy9lbWFpbF0=" />/msg79574.html
> > > > If the filesystem is -draid5 -mraid1 then the metadata is not vulnerable
> > > > to the write hole, but data is. In this configuration you can determine
> > > > with high confidence which files you need to restore from backup, and
> > > > the filesystem will remain writable to replace the restored data,
> > > > because
> > > > raid1 does not have the write hole bug.
>
> In regards to my earlier questions, what would change if i do -draid5 -mraid1?
Metadata would be using RAID1 which is not subject to the RAID5 write
hole issue. It is much more tolerant of unclean shutdowns especially
in degraded mode.
Data in RAID5 may be damaged when the array is in degraded mode and
a write hole occurs (in either order as long as both occur). Due to
RAID1 metadata, the filesystem will continue to operate properly,
allowing the damaged data to be overwritten or deleted.This is the link @crashtest should have read long ago since it would prevent him continuing with one of his moronic approaches to 'spread the news about btrfs'. He barely understands anything and feels encouraged to continue spreading BS.
More external links, "explaining things" and deflecting for the simple reality of the "experimental" message in RED in dmeg. How typical and what a strange world to live in. (On the other hand, maybe it's a colorful place with pink elephants and unicorns. )
_____________________________________________________
@savellm ; this is a prime example of what would have happened to your ZFS thread if it didn't go into a PM (a conversation). It would have become so polluted with irrelevant opinions, numerous links to external pages and other nonsense that the core issue would probably still be undiscovered. (Docker containers creating issues in ZFS filesystems.)
_____________________________________________________
Now, since it's pretty obvious that OCD is firmly in the drivers seat, feel free to go on-and-on about the virtues of BTRFS.
I'm done here.
Don’t have an account yet? Register yourself now and be a part of our community!