Post #2968432

Briefly addressing the RAID types you mentioned: - **RAID-0:** OH NO OH GOD PLEASE NO AHHHHHHH - **RAID-1:** There's nothing wrong with it, but it feels very weird to me that BTRFS can do RAID-1 over 3 disks. It's still technically 2 copies of every block, meaning you can in theory lose any single drive and still recover the data, but idk, it just *feels wrong*. - **RAID-10:** Again, weird that BTRFS allows this with an odd amount of disks. From what I can find, this has no advantage over RAID-1 with 3 disks and can in fact perform worse. - **RAID-5:** It's probably fine if you have backups, and you get the most usable space out of your disks, but performance will take a hit, and scrubs are terribly slow. Now, you mentioned not wanting ZFS due to complexity, but really, it is no more complex to manage than BTRFS. It's fairly easy to get it working on any modern Linux distro (Ubuntu has support out-of-the-box, Debian has it packaged as a DKMS module, Arch has it in AUR, and so on). With ZFS, you could create a RAID-Z1 (equivalent to a RAID-5) without any of the performance penalties or risks that BTRFS RAID-5 has. Both have pretty much them same features, with the main difference that ZFS can't be "re-balanced" to a different disk layout like BTRFS can, but it will also generally not corrupt your data if you look at it wrong. Everything else maps pretty much 1:1 between them. Both support: - Transparent compression - Transparent checksums - Scrubbing - Snapshots - Block-level transfers (btrfs-send / zfs-send) - Fairly intuitive CLI - Filesystem (BTRFS) == Pool (ZFS) - Subvolume (BTRFS) == Dataset (ZFS)