Har kört BTRFS i raid 5 ett tag och tycker mig inte se några problem, dessutom är refererade inlägget från 2016 och det gjordes en stor förbättring av situationen hösten 2017 där både scrub och balance kan reparera i dom situationerna i RAID5/6 som innan dess var ett problem med (fans ingen verktyg för kontroll och reparation innan detta), det som dock inte är fixat är 'write hole' när det är 2 saker som sker samtidigt - att en disk havererar samtidigt som det bryts mitt under skrivningar av tex. strömavbrott. och det är ganska många RAID-system som ännu idag har sådana problem inklusive den allmänt erkända MDADM (finns patch eller näst intill exprimentell kod för det för MDADM, men är normalt inte aktiverat som standard hos Ubuntu med flera då sådan kostar prestanda...
Men det är klar att det alltid finns någon extremsituation då en RAID kan välta - men gäller alla RAID med var och en sina svagheter
RAID är heller ingen ingen ursäkt att inte också ha regelbundet uppdaterad backup, då RAID är en tillgänglighetsförbättring (systemet fungerar även om man har trasiga diskar) - inte att det är en bättre dataskydd!!
ZFS är tyngre att köra och kräver mer minne och har också sina problem när vissa 'olyckor' händer och det då är enormt viktigt att man gör saker i rätt ordning av ZFS-haverikunniga människor om inte RAID:en skall förloras.
Problemet med RAID-havrerier i allmänhet är att det sker så sällan och alla är nybörjare för situationen när det väl händer, ofta som blixt från klar himmel alternativt man ignorera att byta diskar fast varnat i kanske åratal innan (bortglömd server i en skrubb som när den pajar visade sig att hela företaget blir förlamat för att olika funktioner plötsligt slutar att fungera), och dessutom kan haverierna ske på olika sätt med var och en sin lösning om RAID skall vara räddningsbar.
Se till istället att ha regelbunden backup så att det inte är för mycket som förloras eller kräver kostsam konsultation för att rädda RAID den dagen när det skiter sig.
---
Köpe-NAS använder förvisso också btrfs (i princip alla som är tänkta att kunna hantera diskararrayer över 8 - 16 TB) för funktioner som är svårare med äldre filsystem som ext4 (snapshot, komprimerande filsystem, checkumma på både data och metadata etc.), men läggs traditionellt som JBOD/RAID0 ovanpå en MDADM-RAID där, som sköter själva diskarna - mest för att de kan det bäst och känner sig trygga med det.
Det finns dock en sak man skall vara noga med köpeNAS och BTRFS - alltid 64-bits processor (kolla noga!!), är det 32-bit, ha aldrig större logiska RAID-volymer på mer än 16 TB - helst inte över 8 TB (ext4 har samma bekymmer när volymerna är över 16 TB, 32-bitas processorer hanterar det inte bra eller ens alls när man precis går över 16TB-sträcket och det är tyvärr sällan programmen varnar eller hindrar det vid tex. formatering för det eftersom både kodbasen och filsystemen som sådan hanterar lätt över 16 TB - väldigt mycket mer än så faktiskt - _OM_ det är på 64-bits processor)
(det verkar som ext4 också har nyupptäckta allvarliga buggar (BLK-MQ) fast filsystemet som sådan är att anses som väldigt moget)