Ha en trevlig helg allihopa! Vi bjuder in dig till en gratis demonstrationslektion , som kommer att ledas av Andrey Buranov, en UNIX-systemspecialist på Mail.Ru Group. Vi publicerar också en artikel av Jonathan Corbet - chefredaktör i LWN.net.
Journalföring av filsystem lovar att befria systemadministratörer från besväret med diskkorruption när ett system kraschar. Även utan att köra en integritetskontroll av filsystemet. Även om allt i verkligheten naturligtvis är lite mer komplicerat. Och som en nyligen genomförd diskussion visar kan det vara ännu mer förvirrande än många av oss inser, eftersom det har prestandakonsekvenser att säkerställa integriteten hos journalförda filsystem.
Ett filsystem som ext3 använder ett separat område på disken som kallas en journal. När ändringar görs i filsystemets metadata skrivs dessa ändringar först till journalen utan att resten av filsystemet ändras. När alla ändringar har skrivits till loggen läggs ett "commit-block" till, vilket indikerar att transaktionen är slutförd. Och först efter att commit-blocket har skrivits, committeras transaktionen och de ändrade metadata skrivs till disk. Om systemet någonsin kraschar kan informationen i loggen användas för att säkert stänga av systemet och undvika att filsystemet skadas på grund av att endast en del av metadata uppdateras.
Det finns dock en hake: filsystemskoden måste vara helt säker på att all transaktionsinformation redan har skrivits till loggen innan commit-blocket skrivs. Att bara skriva operationer i rätt ordning räcker inte – moderna hårddiskar har stora interna cacheminnen och ordnar om operationer för att förbättra prestandan. Därför är det nödvändigt att uttryckligen ange att all loggdata ska flyttas till disk innan commit-blocket. Om commit-blocket skrivs tidigare kan loggen bli skadad. Barriärer används för att lösa detta problem. I huvudsak förhindrar en barriär att block som skrivs efter barriären skrivs tills alla block som skrivits före barriären har skrivits till disk. Genom att använda barriärer säkerställer filsystem konsekvens i filstrukturer.
Men det finns ett annat problem: ext3- och ext4-filsystem använder inte barriärer som standard. Alternativet finns där, men om inte administratören uttryckligen aktiverar dem fungerar dessa filsystem utan hinder, även om standardvärdena är annorlunda i vissa distributioner (till exempel SUSE). Eric Sandeen beslutade nyligen att den här situationen behövde förändras och , vilket ändrar standardinställningarna för ext3 och ext4. Och sedan började en hetsig diskussion.
Andrew Morton i detalj , varför är standardvärdet exakt så här:
Förra gången vi försökte ändra detta sjönk prestandan på många arbetsbelastningar med 30 %, så jag kastade ut alla de där patcharna i fasa. Jag tror inte att vi kan göra det och sakta ner alla maskiner så mycket...
Det finns inga perfekta lösningar här, och jag tenderar att lämna den sovande hunden ifred och låta standardinställningarna bestämmas av distributionsutvecklarna.
Således är barriärer inaktiverade som standard eftersom de har en betydande inverkan på prestandan. Dessutom används filsystem ganska framgångsrikt utan hinder. Rapporter om korruption i ext3-filsystemet är sällsynta.
Men det är inte bara tur. Ted Ts'o Detta beror på att ext3/ext4-journalen vanligtvis är placerad sammanhängande. Först försöker filsystemdrivrutinen att göra den sammanhängande. För det andra skapas journalen vanligtvis samtidigt som filsystemet, när sammanhängande utrymme är lätt att hitta. Kontinuitet och ordning är inte bara användbara för produktiviteten, utan också för att förhindra omordning. Vanligtvis placeras commit-blocket omedelbart efter resten av informationen i journalen, så det finns ingen anledning att ändra ordning på disken. Commit-blocket skrivs naturligtvis till disken omedelbart efter resten av loggposterna.
Ingen påstår dock att det alltid kommer att vara så. Hårddiskar kan bete sig annorlunda. Dessutom är journalen en cirkulär buffert. Därför, när en transaktion skrivs till slutet av loggen, kan commit-blocket hamna i ett tidigare block, före andra loggposter. Så det finns alltid en risk för skador. Faktum är att Chris Mason har en för det. . Det råder ingen tvekan om att det är mindre säkert att arbeta utan barriärer än att arbeta med dem.
Om du är villig att ta en spark i produktiviteten kan du aktivera hinder. I det fallet förstås när ditt filsystem inte är baserat på LVM (som i vissa distributioner som standard). Det visar sig att enhetsmapparen inte stöder barriärer. I andra fall vore det bra att minska prestandaförsämringen. Och det ser ut som att det kan göras.
Den nuvarande ext3-implementeringen (när barriärer är aktiverade) utför följande operationssekvens för varje transaktion:
Data skrivs till loggen
Barriären implementeras
Commit-blocket är skrivet
Nästa hinder möts
Senare spolas metadata till disk.
I ext4 kan den första barriären (steg 2) utelämnas eftersom ext4-filsystemet hanterar kontrollsummor i journalen.
Om loggdata och commit-blocket ändras och operationen avbryts på grund av ett fel, kommer loggkontrollsumman inte att matcha den som lagras i commit-blocket och transaktionen kommer att avvisas.
Chris Mason , att det skulle vara "generellt säkert" att ta bort denna barriär även i ext3, med det möjliga undantaget att journalen når slutet och börjar skriva från början.
En annan idé för att påskynda saker och ting är att skjuta upp barriäroperationer när det är möjligt. Om det inte finns något akut behov av att omedelbart spola data till disk, kan du skapa flera transaktioner i loggen och spola till disk med en enda barriär.
Det finns också viss potential för förbättringar genom att noggrant ordna operationer så att barriärer (som vanligtvis implementeras som "spola alla väntande operationer till disk"-förfrågningar) inte tvingar fram skrivningar av block som inte kräver ordning.
Det verkar som att det är dags att fundera på hur man kan göra kostnaden för barriärer acceptabel. Ted Tso verkar vara :
Jag tycker att vi borde aktivera barriärer i ext3/4 och sedan arbeta med att minska overhead i ext4/jbd2. Troligtvis fungerar den stora majoriteten av system inte under förhållanden som de som Chris använde för att demonstrera problemet, och standardsäkerhet för filsystem bör prioriteras.
Sunt förnuft säger mig att den här hunden inte längre sover och förmodligen kommer att skälla ett tag framöver. Detta kan störa vissa grannar, men det är bättre än att låta henne bita.
Är du intresserad av att utvecklas i denna riktning? Registrera dig för en gratis demonstrationslektion och delta i sändningen , som kommer att ledas av Pavel Vikiryuk - MVNO-telekomoperatör, DevOps-ingenjör.
Källa: will.com
