Men i grunden är det inte BTRFS som hanterar RAID-funktionen - det är en mdadm-RAID som BTRFS sedan ligger ovanpå.
BTRF har dock checksumma på alla sina sektorer och skulle det blir fel i den underliggande RAID-hanterande och fel data skulle levereras tillbaka så kommer BTRFS att reagera på detta - dock inte kunna rätta det då den inte har kontroll på de underliggande diskarna och dess paritet.
Hade BTRFS själv skött om sin RAID så hade den kunna provat de olika alternativen som erbjuds från de olika diskarna och välja den första som levererar rätt data som stämmer med checkumman (lagrad på annan plats på disken) och sedan rätta den disken som hade fel data.
RAID1 ala mdadm har lägen som den inte kan reda ut - tex. i fallet med en strömavbrott och den ena disken har blivit uppdaterad men inte den andra disken och när strömmen slås på igen så kommer RAID-systemet att se två diskar, ingen ger läsfel men datat skiljer sig när samma LBA-nummer läses - detta är en situation som mdadm-RAID inte kan lösa då inget indikerar vilket av dessa två är den korrekta och raid-systemet stallar. Detta kallas för 'write hole' i RAID-sammanhang och är också detta som gör att man inte säger att BTRFS RAID5 och 6 är lämplig att ha i skarp drift för att man kan nå den situationen vid strömavbrott under skrivning och en disk går sönder samtidigt[1] - och sanningen är att mdadm också har den situationen (och utan att någon disk behöver gå sönder) men det verkar alla blunda för och inte låtsas om, då om man skulle applicera samma regler som man gör på BTRFS RAID 5 och 6 så skulle mdadm också bli rödflaggad - och det är den för väletablerad för att någon skulle våga ta det steget...
Det finns möjlighet att slå på mdadm i journalförade mode (är dock ganska mycket beta) men innebär rejäla prestandanedsättning då data skall skrivas två gånger så därför är det normalt sett inte påslaget.
ZFS har motsvarande men där man dedikerat en hel disk eller SSD för rollen (SLOG) för att just hantera situationer med plötslig strömavbrott mitt under skrivoperationer.
Till det har man ytterligare delen att datat som är kvar i RAM och inte synkas till diskarna ännu - försvinner vid strömavbrott och har man en server med 64 GB RAM och mycket aktiviteter så kan det vara ganska mycket som aldrig hinns ned till diskarna...
Kort sagt plötslig strömavbrott är inte bra oavsett och det är bra med UPS som också signalerar till servern att strömmen har gått efter kortare tid så att det hela kan stängas ned på kontrollerat sätt.
---
Hur påverkas det i praktiken med mdadm:s tillkortakommande och olycklig strömavbrott? förmodligen väldigt lite, BTRFS är transaktionshanterande vilket innebär att ingen fil är offentligt skriven förrän transaktionen är genomförd och det sker ofta och kanske som längst 1 ggr per minut om något finns att skriva till disk ur RAM-minnena - har det hunnit halvvägs med en skrivning och bryts mitt i av tex strömavbrott - så backar BTRFS till transaktionen innan och det som skrevs efter denna punkt finns inte (och med stor sannolikhet finns eventuell skillnad i skrivningarna mellan RAID-diskar nu är i den datadelen som övergetts och ingen kommer att titta i den delen och där upptäcka eventuella datafel där - då när det skrivs på nytt så är det med ny data igen och problemet borta.)
[1] det är inte bara det, Jag provat BTRFS i RAID5 i en testrigg med som det visade sig två bråkande diskar samtidigt som krånglade i olika omgångar och en blev utkastad, en disk var redan känd med många reallokerade block och därför användes för att stressa RAID5 lite - den andre var en överraskning och visade sig först vid synkning - trots att jag nog gjorde alla fel som gick, så tappade jag ingen data och tom. dubbelkollade med binär-jämförelser med backup - men det som talar emot fortsatt användning i skarp drift ännu, var att man inte fick systemet 'clean' med reparationer och städning efteråt - fast detta var vid användning helt stabilt så fortsatte dmesg att kräkas felmeddelande som man inte kunde bli kvitt i trots att man kört balance, check och scrub mm. och man tycker det borde ha försvunnit.
Mao. det fungerar jättefint - när disk bråkar så fungerar det fortfarande, även vid dubbeldisk-fel fungerade och data blandades inte ihop, så länge att just datadelen som söktes inte var trasigt på båda diskarna samtidigt, när ny disk sätts in fungerar det fortfarande, MEN - man blir inte av med alla (oväsentliga/falska positiv?) felmeddelanden som hela tiden produceras i dmesg efter en diskbytar-händelse. Till detta så är inte BTRFS diskhantering automatisk när man byter disk på samma sätt som mdadm-RAID utan kräver kommandon skrivs för momenten. Med andra ord finns en del kvar att städa i BTRFS RAID5/6 men inget uppenbart av naturen att det orsakat att man förlorat filer - tvärt om, filerna verkar vara synnerligen resilenta trots att RAID-systemet var allt annat än stabil pga. i omgångar dubbla bråkande diskar i en RAID5, så även om det skiter sig ganska rejält så är räddningspotentialet av felfria filer ur en havererad BTRFS 5/6 mycket hög - normala havererade RAID brukar vara rätt hopplösa i det läget...
