För Linux-kärnan 6.2 kommer förbättringar av RAID5/6 i Btrfs att införas

För att aktivera kärnan i Linux 6.2 föreslås förbättringar av Btrfs som handlar om att åtgärda problemet med "write hole" i implementeringen av RAID 5/6. Kärnan i problemet är att om det inträffar ett systemkraschar under skrivning är det från början omöjligt att avgöra vilken block på vilket av RAID-enheterna har skrivits korrekt, och vilken skrivning inte har slutförts. Vid ett försök att återställa RAID i en sådan situation kan block som motsvarar de ofullständigt skrivna blocken skadas eftersom statusen för RAID-blocken blir desynkroniserad. Detta problem uppstår i alla RAID1/5/6-arrayer där inga särskilda åtgärder vidtas för att motverka ett sådant effekt.

I implementeringen av RAID, liknande RAID1 i btrfs, löses detta problem genom att använda kontrollsummor i båda kopiorna; vid skillnad återställs data helt enkelt från den andra kopian. Denna metod fungerar också om en enhet börjar ge felaktiga data i stället för ett totalt fel.

Men i fallet med RAID5/6 lagrar filsystemet inte kontrollsummor för paritetsblock; i normala situationer verifieras blockens korrekthet av det faktum att alla är märkta med kontrollsumma, och paritetsblocket kan återskapas från data. Men vid partiell skrivning kan denna metod i vissa situationer misslyckas. I detta fall, vid återställning av arrayen, är det möjligt att block som har påverkas av ofullständig skrivning kan återställas felaktigt.

För btrfs är detta problem mest aktuellt om den skrivna datan är mindre än stripe-storleken. I så fall måste filsystemet utföra en läs-modifiering-skrivning (read-modify-write, RMW) operation. Om det stöter på block med ofullständig skrivning, kan RMW-operationen orsaka korruptioner som inte kommer att upptäckas, trots kontrollsummor. Utvecklarna har infört ändringar där RMW-operationen kontrollerar blockens kontrollsummor innan operationen utförs, och vid behov, när datan återställs, verifierar kontrollsummorna efter skrivningen. Tyvärr leder denna metod för att hantera ofullständig stripe-skrivning (RMW) till extra overhead för att beräkna kontrollsummor, men det ökar betydligt tillförlitligheten. För RAID6 är en sådan logik ännu inte klar, men för ett fel i RAID6 krävs det att skrivningen misslyckas på två enheter samtidigt, vilket är mindre sannolikt.

Det bör också noteras rekommendationerna från utvecklarna angående användningen av RAID5/6, som i korthet innebär att i Btrfs kan lagringsprofilen för metadata och data skilja sig åt. Här kan man använda RAID1-profilen (spegel) eller till och med RAID1C3 (3 kopior) för metadata, medan man för data kan använda RAID5 eller RAID6. Detta ger en pålitlig skydd för metadata och eliminerar "write hole" på ena sidan, samt en mer effektiv användning av utrymme som kännetecknas av RAID5/6 på andra sidan. Detta hjälper till att undvika korruptioner i metadata, och datakorruptioner kan åtgärdas.

Det är också värt att nämna att för SSD kommer Btrfs i kärna 6.2 som standard att aktivera asynkron utförande av operationen "discard" (markera frigjorda block som inte längre behöver lagras fysiskt). Fördelen med detta läge är hög prestanda tack vare effektiv gruppering av "discard"-operationer i köer och fortsatt behandling av köen av en bakgrundsbehandlare, vilket gör att normala filsystemoperationer inte fördröjs, till skillnad från vid synkron "discard" när block frigörs, och SSD kan fatta bättre beslut. Å andra sidan kommer det inte längre att vara nödvändigt att använda verktyg som fstrim, eftersom alla tillgängliga block kommer att rensas i filsystemet utan behov av ytterligare skanning och utan att verksamheterna saktas ner.

Källa: opennet.ru