Önskar alla en utmärkt helg! Vi bjuder in till en gratis demo-lektion , som kommer att hållas av Andrey Buranov — specialist på UNIX-system inom Mail.Ru Group. Vi publicerar också en artikel av Jonathan Corbet — Executive Editor på LWN.net.
Journaliserade filsystem lovar att befri de systemadministratörer från problem med diskfel vid systemkrascher. Även utan att köra en integritetskontroll av filsystemet. Men i verkligheten är allt lite mer komplicerat. Och som nyligen diskussioner visar, kan det vara mer förvirrande än många av oss tror, eftersom integriteten hos journaliserade filsystem påverkar prestandan.
Ett filsystem som ext3 använder ett separat område på disken, kallat journal. När ändringar görs i filsystemets metadata, registreras dessa ändringar först i journalen utan att påverka resten av filsystemet. Efter att alla ändringar har skrivits till journalen läggs en "commit block" till, som markerar avslutandet av transaktionen. Endast efter att commit-blocket har skrivits, fastställs transaktionen och de ändrade metadata skrivs till disken. Om systemet kraschar någon gång, kan informationen i journalen användas för att avsluta arbetet säkert och förhindra skador på filsystemet, eftersom endast en del av metadata har uppdaterats.
Men det finns en hake: koden för filsystemet måste innan commit-blocket skrivs vara helt säker på att all information om transaktionen redan har nått journalen. Det är bara att registrera operationerna i rätt ordning som inte är tillräckligt — moderna diskar stöder stora interna cache-minnen och omordnar operationer för att förbättra prestandan. Därför måste det uttryckligen anges innan commit-blocket att alla data i journalen ska överföras till disken. Om commit-blocket skrivs tidigare kan journalen bli korrupt. För att lösa detta problem används barriärer. I själva verket förbjuder en barriär registreringen av eventuella block efter barriären, tills alla block som registrerades före barriären har överförts till disken. Genom att använda barriärer garanterar filsystemen konsistens i filstrukturerna.
Men det finns ett annat problem: filsystemen ext3 och ext4 använder som standard inte barriärer. Det finns en alternativ inställning, men om administratören inte har aktiverat dem uttryckligen, fungerar dessa filsystem utan barriärer, även om vissa distributioner (till exempel SUSE) har andra standardvärden. Eric Sandeen har nyligen beslutat att denna situation måste ändras och , som modifierar standardinställningarna för ext3 och ext4. Och då började en livlig diskussion.
Andrew Morton svarade mycket utförligt Senast vi försökte ändra detta försämrades prestandan under många belastningar med 30 %, så jag skrek av skräck och kastade bort alla dessa patchar. Jag tror inte att vi kan tillåta att det saktar ner alla maskiner så mycket...
Här finns det inga perfekta lösningar, och jag lutar åt att inte väcka den sovande hunden och lämna standardparametrarna till distributionsutvecklarna.
Således är barriärerna som standard avstängda, eftersom de har en betydande påverkan på prestandan. Dessutom används filsystemen framgångsrikt utan barriärer. Rapporter om skador på filsystemen ext3 är få och sällsynta.
Men det är inte bara tur. Ted Ts'o
beror på att loggen för ext3/ext4 vanligtvis finns i sammanhängande utrymme. För det första försöker filsystemdrivrutinen skapa det sammanhängande. För det andra skapas loggen oftast samtidigt med filsystemet, när det är lätt att hitta sammanhängande utrymme. Sammanhängande och ordning är bra för både prestanda och för att förhindra omordning. Vanligtvis kommer commit-blocket att placeras direkt efter de övriga uppgifterna i loggen, så disken har inga skäl att omordna. Commit-blocket skrivs naturligt på disken direkt efter de andra loggposterna. Ingen påstår dock att det alltid kommer att vara så. Disklagring kan bete sig annorlunda. Dessutom är loggen en cirkulär buffert. Så när en transaktion skrivs till slutet av loggen, kan commit-blocket hamna i en tidigare post före andra loggposter. Så risken för skada finns alltid. Faktum är att Chris Mason har tester för detta
Тем не менее никто не утверждает, что так будет всегда. Дисковые накопители могут вести себя и по-другому. Кроме того, журнал представляет собой кольцевой буфер. Поэтому когда транзакция записывается в конец журнала, то коммит блок может оказаться в более раннем блоке, перед другими записями журнала. Так что вероятность повреждения есть всегда. На самом деле, у Криса Мэйсона (Chris Mason) есть для этого Det råder ingen tvekan om att arbete utan barriärer är mindre säkert än med dem.
Om du är villig att ta en prestandaisk, kan du aktivera barriärer. Det är dock under förutsättning att ditt filsystem inte är baserat på LVM (som i vissa distributioner som standard). Det visar sig att device mapper inte stödjer barriärer. I andra fall skulle det vara bra att minska prestandaförlusten. Och det verkar vara möjligt.
Den nuvarande implementeringen av ext3 (när barriärer är aktiverade) utför följande sekvens av operationer för varje transaktion:
Data skrivs till loggen
En barriär utförs
Commit-blocket skrivs
Nästa barriär utförs
Senare skrivs metadata till disken
I ext4 kan den första barriären (steg 2) utelämnas, eftersom ext4-filsystemet stöder kontrollsummor i loggen.
Om loggdata och commit-blocket omordnas, och operationen avbryts på grund av ett fel, kommer kontrollsumman i loggen inte att stämma överens med den som lagras i commit-blocket, och transaktionen kommer att avvisas.
Chris Mason , skulle det vara "övergripande säkert" att ta bort denna barriär även i ext3, med möjliga undantag när loggen når slutet och börjar skriva från början.
En annan idé för att öka hastigheten är att skjuta upp barriäroperationer när det är möjligt. Om det inte finns ett akut behov av att omedelbart skriva data till disken, kan man skapa flera transaktioner i loggen och skriva till disken med en barriär.
Det finns också potential för förbättring genom att noggrant ordna operationerna så att barriärer (som vanligtvis implementeras som förfrågningar "skriv alla fördröjda operationer till disken") inte tvingar att skriva block som inte kräver ordning.
Det verkar som att det är dags att tänka på hur man gör kostnaden för barriärer acceptabel. Ted Ts'o verkar :
Jag tror att vi bör inkludera barriärer i ext3/4 och sedan arbeta på att minska overheaden i ext4/jbd2. Förmodligen arbetar de flesta system inte under förhållanden som de Chris använde för att demonstrera problemet, och säkerheten för filsystemet bör prioriteras.
Sunt förnuftet mig säger att denna hund redan är vaken och troligtvis kommer att skälla ett tag. Detta kan orsaka oro för vissa grannar, men det är bättre än att låta den bita.
Är du intresserad av att utvecklas inom detta område? Anmäl dig till en gratis demo-lektion och delta i sändningen , som hålls av Pavel Vikiryuk – MVNO-operatör, DevOps-ingenjör.
Källa: habr.com
