Linux Kernel
Det avslöjades nyligen förbättringar av Btrfs föreslogs för inkludering i Linux 6.2-kärnan för att fixa skrivhålsproblemet i RAID 5/6-implementering.
Kärnan i problemet bottnar i det faktum att om en krasch inträffar under inspelningen är det initialt omöjligt att förstå vilket block på vilken av RAID-enheterna som skrevs korrekt och på vilken inspelningen inte slutfördes.
Om du försöker bygga om en RAID i den här situationen kan blocken som motsvarar de prenumererade blocken bli skadade eftersom tillståndet för RAID-blocken är osynkroniserat. Det här problemet uppstår i alla RAID1/5/6-arrayer där inga speciella åtgärder vidtas för att bekämpa denna effekt.
I en RAID-implementering som RAID1 i btrfs är detta problem löst genom att använda kontrollsummor på båda kopiorna, om det finns en oöverensstämmelse, återställs data helt enkelt från den andra kopian. Detta tillvägagångssätt fungerar också om någon enhet börjar ge dålig data istället för att misslyckas helt.
Sin embargo, i fallet med RAID5/6 lagrar inte filsystemet kontrollsummor för paritetsblock - i en normal situation kontrolleras blockens riktighet genom att de alla är utrustade med en kontrollsumma, och paritetsblocket kan återskapas från datan. Men vid partiell inspelning kanske detta tillvägagångssätt inte fungerar i vissa situationer. I detta fall, när du återställer arrayen är det möjligt att blocken kvar i den ofullständiga posten är felaktigt återställda.
När det gäller btrfs är detta problem mer relevant om skrivningen som uppstår är mindre än randen. I det här fallet måste filsystemet utföra en läs-modifiera-skrivoperation (RMW).
Om den stöter på blockeringar som pågår skrivning, kan RMW-operationen orsaka korruption som kommer att förbli oupptäckt, oavsett kontrollsummor. Utvecklarna har gjort ändringar där RMW-operationen verifierar kontrollsumman för blocken innan den här operationen utförs, och vid behov utför dataåterställningen även en kontrollsummaverifiering efter skrivning.
Tyvärr, i en situation där en ofullständig frans (RMW) skrivs, skapar detta ytterligare overhead för att beräkna kontrollsummorna, men ökar tillförlitligheten avsevärt. För RAID6 är sådan logik inte klar än,
Dessutom kan vi notera rekommendationerna om användningen av RAID5/6 från utvecklarna, vars kärna är att profilen för lagring av metadata och data i Btrfs kan skilja sig åt. I det här fallet kan du använda profilen RAID1 (spegel) eller till och med RAID1C3 (3 kopior) för metadata och RAID5 eller RAID6 för data.
Detta säkerställer å ena sidan tillförlitligt metadataskydd och frånvaron av ett "skrivhål", å andra sidan mer effektiv användning av utrymmet, typiskt för RAID5/6. Detta förhindrar korruption av metadata och datakorruption kan korrigeras.
också Det kan noteras att för SSD:er på Btrfs i kärnan 6.2, la asynkron exekvering av "kassera"-operationen (markera frigjorda block som inte längre kan lagras fysiskt) kommer att vara på som standard.
Fördelen med detta läget är högpresterande på grund av effektiv gruppering av kasseringsoperationer i en kö och efterbearbetning av kön av en bakgrundshanterare, så att normala FS-operationer inte saktas ner som är fallet med synkront "kassera" eftersom block frigörs, och SSD:n kan bli bättre beslut. Å andra sidan behöver du inte längre använda verktyg som fstrim, eftersom alla tillgängliga block kommer att raderas i FS utan behov av ytterligare skanning och utan att sakta ner operationerna.
Slutligen, om du är intresserad av att kunna veta mer om det, kan du konsultera detaljerna i följande länk.