Btrfs-forbedringer er blevet foreslået til inklusion i Linux 6.2-kernen for at løse "skrivehul"-problemet i RAID 5/6-implementeringen. Essensen af problemet kommer ned til, at hvis der opstår et nedbrud under optagelsen, er det i første omgang umuligt at forstå, hvilken blok på hvilken RAID-enhed der er skrevet korrekt, og i hvilken optagelsen ikke blev afsluttet. Hvis du forsøger at gendanne en RAID i denne situation, kan de blokke, der svarer til de underskrevne blokke, blive ødelagt, fordi RAID-blokkenes tilstand er ude af synkronisering. Dette problem opstår i alle RAID1/5/6-arrays, hvor der ikke er truffet særlige foranstaltninger for at bekæmpe denne effekt.
I en RAID-implementering, som RAID1 i btrfs, løses dette problem ved at bruge kontrolsummer i begge kopier; hvis der er et misforhold, gendannes dataene simpelthen fra den anden kopi. Denne tilgang virker også, hvis en enhed begynder at sende forkerte data i stedet for en fuldstændig fejl.
I tilfælde af RAID5/6 gemmer filsystemet dog ikke kontrolsummer for paritetsblokkene: I en normal situation verificeres blokkenes gyldighed ved, at de alle er checksummerede, og paritetsblokken kan rekonstrueres fra dataene. Men i tilfælde af delvis optagelse fungerer denne tilgang muligvis ikke i visse situationer. I dette tilfælde, når du gendanner et array, er det muligt, at blokke, der falder ind under en ufuldstændig post, vil blive gendannet forkert.
I tilfælde af btrfs er dette problem mest relevant, hvis pladen, der produceres, er mindre end striben. I dette tilfælde skal filsystemet udføre en read-modify-write-operation (read-modify-write, RMW). Hvis dette støder på blokke med ufuldstændig skrivning, kan RMW-handlingen forårsage korruption, som ikke vil blive opdaget, uanset kontrolsummerne. Udviklerne har foretaget ændringer, hvor RMW-operationen kontrollerer kontrolsummen af blokke, før denne operation udføres, og hvis det er nødvendigt at gendanne data, tjekker den også kontrolsummerne efter registrering. Desværre, i situationen med at skrive en ufuldstændig stribe (RMW), fører dette til yderligere overhead til beregning af kontrolsummer, men øger pålideligheden betydeligt. For RAID6 er en sådan logik endnu ikke klar, men for en sådan fejl i RAID6 er det nødvendigt, at skrivningen fejler på 2 enheder på én gang, hvilket er mindre sandsynligt.
Derudover kan vi bemærke anbefalinger til brug af RAID5/6 fra udviklerne, hvis essens er, at metadata- og datalagringsprofilen i Btrfs kan være anderledes. I dette tilfælde kan du bruge profilen RAID1 (spejl) eller endda RAID1C3 (3 kopier) til metadata og RAID5 eller RAID6 til data. Dette sikrer pålidelig metadatabeskyttelse og fraværet af et "skrivehul" på den ene side og mere effektiv udnyttelse af plads, karakteristisk for RAID5/6, på den anden side. Dette gør det muligt at undgå korruption af metadata, og datakorruption kan rettes.
Det kan også bemærkes, at for SSD'er i Btrfs i kerne 6.2, vil den asynkrone udførelse af "discard"-operationen blive aktiveret som standard (markering af frigjorte blokke, der ikke længere skal lagres fysisk). Fordelen ved denne tilstand er høj ydeevne på grund af den effektive gruppering af "kasser"-operationer i en kø og yderligere behandling af køen af en baggrundsprocessor, hvilket er grunden til, at normale FS-operationer ikke bliver langsommere, som det er tilfældet med synkrone " kassere”, da blokke frigives, og SSD’en kan træffe bedre beslutninger. På den anden side behøver du ikke længere bruge hjælpeprogrammer som fstrim, da alle tilgængelige blokke vil blive ryddet i FS uden behov for yderligere scanning og uden at bremse operationerne.
Kilde: opennet.ru