Jag har kört BTRFS rätt mycket och är typ 3 - 4 året utan oväntad incident (dock har jag framkalla incidenter för att tex se hur BTRFS recovery-program kan få fram filer igen ur en havererad filsystem - till skillnad från NTFS så har den ett antal magic word och andra markörer samt kännedom hur B-tree i BTRFS fungerar i detalj som gör att det mesta datat går att återvinna i felfri form, med korrekt path, rättighter, tidsstämpar etc., dessutom om man vill kan man ha dubbel/RAID-uppsättning av metadatat och den andre är kvar om de första blir sönderskriven av någon orsak tex vid en diskstängning/avmontering (det var så jag förlorade data i NTFS när jag gjorde rätt enligt konsten alla regler i windows, hade jag bara ryckt ut USB-sladden utan avmontering före så hade det klarat sig...)) och tycker nog att BTRFS får ibland oförskämt mycket skit, med ibland med hänvisning i dag rätt gamla saker och många av dem redan fixade då det åtminstone med min användarmönster har fungerat alldeles utmärkt och är väldigt resilient och ger alltid en filsystem som går att använda på tex. backupdiskar trots att man klantat sig med både kraftförsörjningar och glappa USB3-kontakter mitt under skrivningar med hög datamängd , inklusive på disksets med mer än en drive tills samma filsystem då man lätt utökar när förra disken blir full.
Det är sant att BTRFS kanske inte når upp till ZFS när det gäller datasäkerhet, men å andra sidan så är det mycket mer flexibelt och det är känt att det finns några corner cases som den ännu inte hanterar så bra (som tex. en plötslig strömavbrott och en diskhaveri samtidigt, men å andra sidan så har jag folk i bekantskapskretsen som fått havererad ZFS också, sökt hjälp och pratat med de som verkligen kan zfs på närmast nördnivå så att saker och ting i dom lägen görs i exakt rätt ordning för att det hela inte skall haverera ohjälpligt) - men ändå är det hela skyhögt mycket bättre än tex.backuplagring på NTFS, det är på NTFS jag förlorat svidande mängder med data trots alla tänkbara räddningsförsök efter händelsen - tror jag provat alla linux ext-versioner mm. och inte ens varit i närheten i dataförluster (dvs. mer än enstaka filer) som NTFS åsamkade mig...
På de flesta köpeNAS som hanterar mer än 16 TB och/eller erbjuder snapshot för generationsbackupper så körs en BTRFS på en mdadm-RAID, och skiter sig mdadm-RAID så skiter sig också BTRFS ovan på denna då BTRFS inte själv rår om diskarna i den här konfigurationen och det finns flera situationer där man kan haverera en mdadm-RAID som tex plötslig strömavbrott under skrivning.
När man hör folk, både privata och på företag där en köpeNAS havererat efter en strömavbrott - så är det nästa alltid en mdmadm-RAID haveri i botten där RAID har hamnat i en situation där det konstaterar olikhet mellan samma sektornummer på RAID1 eller pariteten inte stämmer med datat som skapade pariteten när det börja läsa in filer, men likt åsna mellan hötappar inte kan avgöra vilket som är rätt data och det hela stallat - då spelar det ingen roll vilken filsystem som är ovanpå RAID då det aldrig kommer ens så långt att det frågar...
Hade BTRFS (och ZFS...) själv rått om diskarna så kanske det var enstaka filer som gick paj om det inte fans nog redundans att reparera och då hade man fått reda på det - inte att hela NAS:ens filer blev inslåsta och inte kommer åt en enda fil...
Skall få bättre strömavbrotts-resilens på en mdadm-RAID så måste man allokera utrymme och aktivera skrivcache (som skrivs fysiskt på disken hela tiden vid diskaktiviteter) och förstås prestandaförlust med detta, och i praktiken inte är påslaget av den orsaken. Man kan förvisso förbättra strömavbrottsresilensen på andra vägar med separat SSD som agerar disk-skrivcache mm. men är lite av lapptäcke än tex. med ZFS.
---
Det finns inget alls som hindrar att man kör ZFS på sin NAS (såvida att det finns tillräckligt med propp och minne för det) och sedan använder BTRFS på sina backupdiskar då det är så otroligt enkelt med snapshot att göra generationsbackupper med BTRFS så att man inte sopar bort sin förra backups original när man med nästa backup skriver över med ransomware-krypterade filer - det enda man ser om det händer och man får ner en oönskad krypterad filsets är att diskutrymme försvinner... - och i situation när disken är full så kopplar man en disk till till sin backupvolym med en 'btrfs dev add /dev/xxxx /mount_backup_fs' och sedan fortsätter man med sin backup som nyss inte fick plats.
Har haft ett par disk-set på det sättet (ovanpå en lucksCrypt på varje disk, och i Ubuntu får man snällt en passordförfrågan för varje disk och när alla är upplåsta för diskseten så monteras BTRFS automagiskt) och det har aldrig hittills misslyckats att montera de två diskarna till en och samma BTRFS-volym och volymen fullt användbar trots 'olyckor' som att man ryckte strömsladden till den ena disken under full backup, det mer än en gång...
Jag personligen gör ingen jämförelse med ZFS då jag helt enkelt inte kört den eller lärt mig vad den kan - då BTRFS helt enkelt har fungerat för bra för min typ av användande att jag inte känt behov att leta vidare i avseende 'bättre' filsystem.