Btrfs-forbedringer er foreslått for inkludering i Linux 6.2-kjernen for å fikse skrivehullsproblemet i RAID 5/6-implementeringen. Essensen av problemet kommer ned til det faktum at hvis det oppstår et krasj under opptak, er det i utgangspunktet umulig å forstå hvilken blokk på hvilken RAID-enhet som ble skrevet riktig, og i hvilken opptaket ikke ble fullført. Hvis du prøver å gjenopprette en RAID i denne situasjonen, kan blokkene som tilsvarer de underskrevne blokkene bli ødelagt fordi tilstanden til RAID-blokkene er ute av synkronisering. Dette problemet oppstår i alle RAID1/5/6-matriser der det ikke er tatt spesielle tiltak for å bekjempe denne effekten.
I en RAID-implementering, som RAID1 i btrfs, løses dette problemet ved å bruke kontrollsummer i begge kopiene; hvis det er et misforhold, gjenopprettes dataene ganske enkelt fra den andre kopien. Denne tilnærmingen fungerer også hvis en enhet begynner å sende feil data i stedet for en fullstendig feil.
Når det gjelder RAID5/6, lagrer imidlertid ikke filsystemet sjekksummer for paritetsblokkene: i en normal situasjon verifiseres gyldigheten av blokkene ved at de alle er sjekksummerte, og paritetsblokken kan rekonstrueres fra dataene. Men i tilfelle av delvis opptak, kan det hende at denne tilnærmingen ikke fungerer i visse situasjoner. I dette tilfellet, når du gjenoppretter en matrise, er det mulig at blokker som faller inn under en ufullstendig post vil bli gjenopprettet feil.
Når det gjelder btrfs, er dette problemet mest relevant hvis platen som produseres er mindre enn stripen. I dette tilfellet må filsystemet utføre en les-endre-skriveoperasjon (lese-endre-skrive, RMW). Hvis dette støter på blokker med ufullstendig skriving, kan RMW-operasjonen forårsake korrupsjon som ikke vil bli oppdaget, uavhengig av kontrollsummene. Utviklerne har gjort endringer der RMW-operasjonen sjekker sjekksummen av blokker før denne operasjonen utføres, og hvis det er nødvendig å gjenopprette data, sjekker den også sjekksummene etter opptak. Dessverre, i en situasjon med å skrive en ufullstendig stripe (RMW), fører dette til ekstra overhead for beregning av sjekksummer, men øker påliteligheten betydelig. For RAID6 er slik logikk ennå ikke klar, men for en slik feil i RAID6 er det nødvendig at skrivingen feiler på 2 enheter samtidig, noe som er mindre sannsynlig.
I tillegg kan vi merke oss anbefalinger for bruk av RAID5/6 fra utviklerne, hvor essensen er at i Btrfs kan metadata- og datalagringsprofilen variere. I dette tilfellet kan du bruke profilen RAID1 (speil) eller til og med RAID1C3 (3 kopier) for metadata, og RAID5 eller RAID6 for data. Dette sikrer pålitelig metadatabeskyttelse og fravær av et "skrivehull", på den ene siden, og mer effektiv bruk av plass, karakteristisk for RAID5/6, på den andre. Dette gjør at metadatakorrupsjon kan unngås og datakorrupsjon kan korrigeres.
Det kan også bemerkes at for SSD-er i Btrfs i kjerne 6.2, vil den asynkrone utførelsen av "kast"-operasjonen bli aktivert som standard (merker frigjorte blokker som ikke lenger trenger å lagres fysisk). Fordelen med denne modusen er høy ytelse på grunn av den effektive grupperingen av "kast" operasjoner i en kø og videre behandling av køen av en bakgrunnsprosessor, som er grunnen til at normale FS-operasjoner ikke bremser ned, slik tilfellet er med synkron " forkast" ettersom blokker frigjøres, og SSD-en kan ta bedre beslutninger. På den annen side vil du ikke lenger trenge å bruke verktøy som fstrim, siden alle tilgjengelige blokker vil bli tømt i FS uten behov for ytterligere skanning og uten å bremse operasjoner.
Kilde: opennet.ru