Btrfs-förbättringar har föreslagits för inkludering i Linux 6.2-kärnan för att fixa skrivhålsproblemet i RAID 5/6-implementeringen. Kärnan i problemet beror på det faktum att om en krasch inträffar under inspelningen är det initialt omöjligt att förstå vilket block på vilken RAID-enhet som skrevs korrekt och i vilken inspelningen inte slutfördes. Om du försöker återställa en RAID i den här situationen kan blocken som motsvarar de underskrivna blocken förstöras eftersom tillståndet för RAID-blocken inte är synkroniserat. Detta problem uppstår i alla RAID1/5/6-arrayer där särskilda åtgärder inte har vidtagits för att bekämpa denna effekt.
I en RAID-implementering, som RAID1 i btrfs, löses detta problem genom att använda kontrollsummor i båda kopiorna; om det inte överensstämmer, återställs data helt enkelt från den andra kopian. Detta tillvägagångssätt fungerar också om någon enhet börjar skicka felaktiga data istället för ett fullständigt fel.
Men i fallet med RAID5/6 lagrar filsystemet inte kontrollsummor för paritetsblocken: i en normal situation verifieras giltigheten av blocken genom att de alla är checksummade, och paritetsblocket kan rekonstrueras från datan. Men vid partiell inspelning kanske detta tillvägagångssätt inte fungerar i vissa situationer. I det här fallet, när du återställer en array, är det möjligt att block som faller under en ofullständig post kommer att återställas felaktigt.
När det gäller btrfs är detta problem mest relevant om skivan som produceras är mindre än stripe. I det här fallet måste filsystemet utföra en läs-modifiera-skrivoperation (läs-modifiera-skriv, RMW). Om detta stöter på block med ofullständig skrivning, kan RMW-operationen orsaka korruption som inte kommer att upptäckas, oavsett kontrollsummorna. Utvecklarna har gjort ändringar där RMW-operationen kontrollerar kontrollsumman av block innan den här operationen utförs, och om det är nödvändigt att återställa data kontrollerar den även kontrollsummorna efter inspelning. Tyvärr, i en situation med att skriva en ofullständig remsa (RMW), leder detta till ytterligare overhead för beräkning av kontrollsummor, men ökar avsevärt tillförlitligheten. För RAID6 är sådan logik ännu inte klar, men för ett sådant fel i RAID6 är det nödvändigt att skrivningen misslyckas på 2 enheter samtidigt, vilket är mindre troligt.
Dessutom kan vi notera rekommendationer för användning av RAID5/6 från utvecklarna, vars kärna är att i Btrfs kan metadata- och datalagringsprofilen 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, karakteristiskt för RAID5/6. Detta gör att metadatakorruption kan undvikas och datakorruption kan korrigeras.
Det kan också noteras att för SSD:er i Btrfs i kärnan 6.2 kommer den asynkrona exekveringen av "kassera"-operationen att aktiveras som standard (markerar frigjorda block som inte längre behöver lagras fysiskt). Fördelen med detta läge är hög prestanda på grund av den effektiva grupperingen av "kassera" operationer i en kö och vidare bearbetning av kön av en bakgrundsprocessor, vilket är anledningen till att normala FS-operationer inte saktar ner, som är fallet med synkrona " kassera” eftersom blocken frigörs och SSD:n kan fatta bättre beslut. Å andra sidan behöver du inte längre använda verktyg som fstrim, eftersom alla tillgängliga block kommer att rensas i FS utan behov av ytterligare skanning och utan att sakta ner operationer.
Källa: opennet.ru