Linux Kernel
Det blev for nylig afsløret forbedringer af Btrfs blev foreslået til inklusion i Linux 6.2 kernen for at løse skrivehulsproblemet i RAID 5/6-implementering.
Essensen af problemet bunder i, at hvis der opstår et nedbrud under optagelsen, er det i første omgang umuligt at forstå, hvilken blok på hvilken af RAID-enhederne der er skrevet korrekt, og på hvilken optagelsen ikke blev afsluttet.
Hvis du forsøger at genopbygge en RAID i denne situation, kan de blokke, der svarer til de abonnerede blokke, blive beskadiget, fordi RAID-blokkenes tilstand er ude af synkronisering. Dette problem opstår i ethvert RAID1/5/6-array, hvor der ikke tages særlige forholdsregler for at bekæmpe denne effekt.
I en RAID-implementering som RAID1 i btrfs er dette problem løst ved at bruge kontrolsummer på begge kopier, hvis der er uoverensstemmelse, gendannes dataene simpelthen fra den anden kopi. Denne tilgang fungerer også, hvis en enhed begynder at give dårlige data i stedet for at svigte fuldstændigt.
Imidlertid i tilfælde af RAID5/6 gemmer filsystemet ikke kontrolsummer for paritetsblokke - i en normal situation kontrolleres blokkenes rigtighed ved, at de alle er udstyret med en kontrolsum, og paritetsblokken kan genskabes ud 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 arrayet, er det muligt at blokkene tilbage i den ufuldstændige post er gendannet forkert.
I tilfælde af btrfs er dette problem mere relevant, hvis den skrivning, der opstår, er mindre end striben. I dette tilfælde skal filsystemet udføre en read-modify-write (RMW) operation.
Hvis den støder på blokeringer, der er i gang med at skrive, kan RMW-handlingen forårsage korruption, der vil forblive uopdaget, uanset kontrolsummer. Udviklerne har foretaget ændringer, hvor RMW-operationen verificerer kontrolsummen af blokkene, før denne operation udføres, og om nødvendigt udfører datagendannelsen også en kontrolsumverifikation efter skrivning.
Desværre, i en situation, hvor en ufuldstændig udkant (RMW) er skrevet, skaber dette yderligere overhead til at beregne kontrolsummerne, men øger pålideligheden betydeligt. Til RAID6 er en sådan logik ikke klar endnu,
Derudover kan vi bemærke anbefalingerne om brugen af RAID5/6 fra udviklerne, hvis essens er, at profilen til lagring af metadata og data i Btrfs kan variere. 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 pladsen, typisk for RAID5/6, på den anden side. Dette forhindrer korruption af metadata, og datakorruption kan rettes.
også Det kan bemærkes, at for SSD'er på Btrfs i kerne 6.2, la asynkron udførelse af "kassere"-operationen (markér frigjorte blokke, der ikke længere kan gemmes fysisk) vil være slået til som standard.
Fordelen ved dette tilstand er høj ydeevne på grund af effektiv gruppering af kasseringsoperationer i en kø og efterbehandling af køen af en baggrundsbehandler, så normale FS-operationer ikke bremses, som det er tilfældet med synkron "kassering", da blokke frigøres, og SSD'en kan gøre det bedre beslutninger. På den anden side behøver du ikke længere bruge hjælpeprogrammer som fstrim, da alle tilgængelige blokke vil blive slettet i FS uden behov for yderligere scanning og uden at bremse operationerne.
Endelig, hvis du er interesseret i at kunne vide mere om det, kan du se detaljerne i følgende link.