God weekend til alle! Vi inviterer til gratis demo-klasse , som vil blive afholdt af Andrey Buranov — specialist i UNIX-systemer hos Mail.Ru Group. Vi offentliggør også en artikel af Jonathan Corbet — Executive Editor hos LWN.net.
Journalerede filsystemer lover at frigøre systemadministratorer fra problemer med diskfejl ved systemnedbrud. Selv uden at køre integritetskontrol af filsystemet. Men i virkeligheden er tingene selvfølgelig lidt mere komplicerede. Som diskussionen for nylig viser, kan det endda være mere indviklet, end mange af os tror, da sikring af integriteten i journalerede filsystemer påvirker ydeevnen.
Et filsystem som ext3 bruger et separat område på disken, kaldet en journal. Når der foretages ændringer i filsystemets metadata, bliver disse ændringer først skrevet til journalen uden at modificere resten af filsystemet. Efter alle ændringer er skrevet til journalen, tilføjes en 'commit-block', der angiver, at transaktionen er afsluttet. Og først efter at commit-blokken er skrevet, bliver transaktionen fixeret, og de ændrede metadata skrives til disken. Hvis systemet går ned på et hvilket som helst tidspunkt, kan informationen i journalen sikkert bruges til at afslutte arbejdet og undgå skader på filsystemet, fordi kun en del af metadataene er blevet opdateret.
Der er dog et problem: filsystemkoden skal være helt sikker på, at al information om transaktionen allerede er kommet ind i journalen, før den skriver commit-blokken. Det er ikke nok bare at skrive operationer i den rigtige rækkefølge — moderne diske understøtter store interne caches og omarrangerer operationer for at forbedre ydeevnen. Derfor skal der eksplicit angives, at alle data i journalen skal overføres til disken, før commit-blokken. Hvis commit-blokken skrives før, kan journalen blive beskadiget. For at løse dette problem bruges barrierer. I sin essens forbyder en barriere at skrive nogen blokke efter barrieren, indtil alle blokke skrevet før barrieren er blevet overført til disken. Ved at bruge barrierer sikrer filsystemer konsistensen i filstrukturerne.
Men der er et andet problem: filsystemerne ext3 og ext4 bruger som standard ikke barrierer. Der er en mulighed, men hvis administratoren ikke har aktiveret dem eksplicit, fungerer disse filsystemer uden barrierer, selvom nogle distributioner (f.eks. SUSE) har andre standardværdier. Eric Sandeen har for nylig besluttet, at denne situation skal ændres, og , der ændrer standardindstillingerne for ext3 og ext4. Og så begyndte den livlige diskussion.
Andrew Morton svarede meget detaljeret Sidste gang vi forsøgte at ændre dette, faldt ydeevnen på mange belastninger med 30%, så jeg kastede skrækslagen alle disse patches væk. Jeg mener, at vi ikke kan tage denne chance og sænke ydeevnen for alle maskiner så alvorligt…
Der er ingen perfekte løsninger, og jeg har en tilbøjelighed til ikke at vække denne sovende hund og lade standardindstillingerne være op til distributionsudviklerne.
Således er barrierer som standard deaktiveret, da de har en alvorlig indvirkning på ydeevnen. Desuden anvendes filsystemer ganske succesfuldt uden barrierer. Rapporterne om beskadigede ext3 filsystemer er få og sjældne.
Men det er ikke bare held. Ted Ts’o
forklarer Dette skyldes, at journalen ext3 / ext4 normalt ligger kontinuerligt. For det første forsøger filsystemdriveren at oprette den kontinuerligt. For det andet oprettes journalen ofte samtidig med filsystemet, når det er nemt at finde kontinuerligt plads. Kontinuitet og orden er nyttige ikke kun for ydeevnen, men også for at forhindre omrokering. Normalt placeres commit-blokken lige efter de øvrige data i journalen, så der er ingen grund til omrokering for disken. Commit-blokken skrives naturligt til disken lige efter de øvrige poster i journalen.
Ingen hævder dog, at dette altid vil være tilfældet. Harddisker kan også opføre sig anderledes. Desuden fungerer loggen som en cirkulær buffer. Så når en transaktion skrives til slutningen af loggen, kan commit-blokken befinde sig i en tidligere blok, før andre poster i loggen. Så der er altid en risiko for korruption. Faktisk har Chris Mason et eksempel på dette. . Der er ingen tvivl om, at arbejde uden barrierer er mindre sikkert end med dem.
Hvis du er villig til at tage et hit på ydeevnen, kan du aktivere barrierer. Dette gælder selvfølgelig, hvis dit filsyste ikke er baseret på LVM (som standard i nogle distributioner). Det viser sig, at device mapper ikke understøtter barrierer. I øvrigt ville det være godt at reducere ydeevneforringelsen. Og det ser ud til, at det kan lade sig gøre.
Den nuværende implementering af ext3 (når barrierer er aktiveret) udfører følgende sekvens af operationer for hver transaktion:
Data skrives til loggen
Barrier udføres
Commit-blokken skrives
Næste barriere udføres
Senere skrives metadata til disk
I ext4 kan den første barriere (trin 2) springes over, da ext4-filesystemet understøtter checksums i loggen.
Hvis logdataene og commit-blokken omrokeres, og operationen afbrydes som følge af fejl, vil checksumen for loggen ikke svare til den, der er gemt i commit-blokken, og transaktionen vil blive afvist.
Chris Mason , at det ville være "generelt sikkert" at fjerne denne barriere også i ext3, med mulige undtagelser, når loggen når slutningen og begynder at skrive fra starten.
En anden idé til at forbedre ydeevnen er at forsinke barrieroperationer, når det er muligt. Hvis der ikke er en presserende grund til straks at skrive data til disk, kan der oprettes flere transaktioner i loggen og skrives til disk med én barriere.
Der er også et vist potentiale for forbedring gennem omhyggelig rækkefølge af operationer, så barrierer (som typisk implementeres som anmodninger om at "skrive alle udestående operationer til disk") ikke tvinger skriveblokke, der ikke kræver rækkefølge.
Det ser ud til, at tiden er inde til at overveje, hvordan omkostningerne ved barrierer kan gøres acceptable. Ted Tso synes at :
Jeg mener, at vi skal inkludere barrierer i ext3/4, og derefter arbejde på at reducere omkostningerne i ext4/jbd2. Sandsynligvis fungerer det overvældende flertal af systemerne ikke under forhold, som dem Chris brugte til at demonstrere problemet, og sikkerheden for filsystemet burde være en prioritet.
Sund fornuft fortæller mig, at denne hund ikke længere sover og sandsynligvis vil gøde i noget tid. Dette kan skabe bekymring hos nogle naboer, men det er bedre end at lade den bide.
Er du interesseret i at udvikle dig inden for dette område? Tilmeld dig et gratis demo-klassetrin og deltag i udsendelsen , som vil blive ledet af Pavel Vikiryuk — MVNO-operations operatør, DevOps-ingeniør.
Kilde: habr.com
