Soovime kõigile head nädalavahetust! Kutsume teid tasuta Demo-tundi , mida viib läbi Andrei Buranov — UNIX-süsteemide spetsialist ettevõttes Mail.Ru Group. Samuti avaldame Jonathan Corbet'i artikli — LWN.net'i peatoimetaja.
Žurnaalitavad failisüsteemid lubavad süsteemiadministraatoritel vabaneda kettavigade probleemidest süsteemi rikete ajal. Isegi ilma failisüsteemi terviklikkuse kontrolli käivitamiseta. Kuigi tegelikult on kõik veidi keerulisem. Ja nagu näitab hiljutine arutelu, võib see olla isegi keerulisem, kui paljud meist arvavad, kuna žurnaalitavate failisüsteemide terviklikkuse tagamine mõjutab jõudlust.
Failisüsteem, näiteks ext3, kasutab eraldi piirkonda kettal, mida nimetatakse žurnaliks. Failisüsteemi metaandmete muutmisel kirjutatakse need muudatused esmalt žurnali, muutes samas ülejäänud failisüsteemi. Pärast kõikide muudatuste salvestamist žurnali lisatakse sinna „kommit blok“, mis näitab tehingu lõpetamist. Ja alles pärast kommit bloki kirjutamist fikseeritakse tehing ning muudetud metaandmed kirjutatakse kettale. Kui süsteem mingil hetkel ebaõnnestub, saab žurnalis olevate andmete abil töö ohutult lõpetada ning vältida failisüsteemi kahjustumist, kuna on värskendatud ainult osa metaandmetest.
Siiski on üks tõrge: failisüsteemi kood peab enne kommit bloki kirjutamist olema täiesti kindel, et kogu tehingu teave on juba žurnali jõudnud. Lihtsalt operatsioonide õiges järjekorras kirjutamine ei piisa — tänapäeva kettad toetavad suuri sisemisi vahemälu ja korraldavad operatsioone ümber jõudluse parandamiseks. Seetõttu tuleb enne kommit bloki kirjutamist selgelt märkida, et kõik žurnali andmed tuleb kettale viia. Kui kommit blok kirjutatakse varem, võib žurnal kahjustuda. Selle probleemi lahendamiseks kasutatakse barreereid. Sisuliselt keelab barjäär kirjutamise mis tahes plokkidele pärast barjääri, kuni kõik barjääri eelnevalt kirjutatud plokid on kettale viidud. Kasutades barreereid, tagavad failisüsteemid failistruktuuride järjepidevuse.
Kuid on veel üks probleem: ext3 ja ext4 failisüsteemid ei kasuta vaikimisi barjääre. Valik on olemas, kuid kui administraator neid selgelt ei lülita, toimivad need failisüsteemid ilma barjäärideta, kuigi mõnedes jaotustes (näiteks SUSE) on vaikeseaded teised. Eric Sandeen otsustas hiljuti, et seda olukorda tuleb muuta ja , mis muudab vaikeseaded ext3 ja ext4 jaoks. Ja siis algas tormiline arutelu.
Andrew Morton vastas väga üksikasjalikult Viimati, kui me proovisime seda muuta, halvenes paljude koormuste tulemuslikkus 30%, seetõttu viskasin ma kõik need plaastrid hirmuga minema. Ma arvan, et me ei saa selle nimel minna ja aeglustada kõigi masinate tööd nii tõsiselt…
Siin pole ideaalseid lahendusi ja ma kaldun mitte äratama seda magavat koera ning jätta vaikeseaded jaotuste arendajate otsustada.
Seega on vaikimisi barjäärid välja lülitatud, kuna need mõjutavad tõsiselt tulemuslikkust. Lisaks kasutatakse failisüsteeme üsna edukalt ka ilma barjäärideta. Teated ext3 failisüsteemi rikkumisest on haruldased.
Kuid see ei ole lihtsalt õnn. Ted Ts’o selgitab
seda sellega, et ext3/4 žurnaal on tavaliselt pidevalt paigutatud. Esiteks üritab failisüsteemi draiver luua selle pidevaks. Teiseks luuakse žurnal tavaliselt samaaegselt failisüsteemiga, kui on lihtne leida pidevat ruumi. Pidevus ja järjekorratus on kasulikud mitte ainult tulemuslikkuse, vaid ka ümberkujundamise vältimise jaoks. Tavaliselt paigutatakse kommiteerimisplokk kohe pärast teisi andmeid žurnal, seetõttu pole kettal põhjus ümber paigutamiseks. Kommiteerimisplokk salvestatakse loomulikult kettale kohe pärast teisi žurnali sissekandeid. see, et ext3 / ext4 ajakiri asub tavaliselt katkematult. Esiteks, failisüsteemi draiver püüab luua selle katkematu. Teiseks, ajakiri luuakse tavaliselt koos failisüsteemiga, kui katkematu ruumi leidmine on lihtne. Katkematus ja korrastatus on kasulikud mitte ainult jõudluse jaoks, vaid aitavad ka ära hoida ümberkorraldusi. Tavaliselt asetatakse kommit blok kohe pärast teisi andmeid ajakirjas, seega pole kettal põhjust ümberkorraldada. Kommit blok kirjutatakse loomulikult kettale kohe pärast ajakirja teisi kirjeid.
Siiski ei väida keegi, et see nii jääb. Kõvakettad võivad käituda teisiti. Lisaks on logi ringikujuline puhver. Seega, kui tehing logisse kirjutatakse, võib kommitplokk sattuda varasemasse plokki, enne kui muud logikirjed. Nii et kahjustuse tõenäosus on alati olemas. Tegelikult on Chris Masonil selle kohta . Pole kahtlustki, et barjääridega töötamine on vähem ohutu kui ilma nendeta.
Kui olete valmis taluma jõudluse langust, siis võite barjääride aktiveerida. Loomulikult juhul, kui teie failisüsteem ei põhine LVM-il (nagu mõnes jaotuses vaikimisi). Selgub, et seadme kaardistaja ei toeta barjääre. Muudel juhtudel oleks hea vähendada jõudluse kahanemist. Ja tundub, et seda on võimalik teha.
Praegune ext3 rakendus (kui barjäärid on lubatud) teostab iga tehingu korral järgmise toimingute jada:
Andmed kirjutatakse logisse
Teostatakse barjäär
Kirjutatakse kommitplokk
Teostatakse järgmine barjäär
Hiljem märgendatakse metainformatsioon kettale
Ext4 puhul saab esimese barjääri (samm 2) vahele jätta, kuna failisüsteem ext4 toetab logis kontrollsummasid.
Kui logi andmed ja kommitplokk on ümber paigutatud ning toiming katkestatakse rikke tõttu, siis logi kontrollsumma ei vasta sellele, mis on salvestatud kommitplokis, ja tehing lükatakse tagasi.
Chris Mason , et oleks "üldiselt ohutu" eemaldada see barjäär ka ext3-st, välja arvatud juhul, kui logi jõuab lõpuni ja hakkab uuesti kirjutama algusest.
Veel üks idee töö kiirusel paranemiseks on edasilükata barjääride toimingud, kui see on võimalik. Kui pole otsest vajadust andmed kohe kettale kirjutada, saab logisse luua mitu tehingut ja kirjutada kettale ühe barjääriga.
Samuti on teatud potentsiaal parandamiseks, hoolikalt korraldades toiminguid nii, et barjäärid (mis tavaliselt on teostatud “kõik ootel operatsioonid kettale kirjutama” päringutena) ei sunniks blokeeringute salvestamist, mis ei nõua korrastatust.
Tundub, et on aeg mõelda, kuidas teha barjääride maksumus vastuvõetavaks. Ted Tso näib :
Ma arvan, et peaksime lisama barrierid ext3/4-sse ja seejärel töötama ext4/jbd2 vähendamise pärast. Tõenäoliselt ei tööta enamik süsteeme tingimustes, sarnastes nendele, mida Kris kasutas probleemi demonstreerimiseks, ning failisüsteemi turvalisus peaks olema prioriteet.
Mulle ütleb terve mõistus, et see koer ei maga enam ja ilmselt hakkab ta mõnda aega haukuma. See võib tekitada muret mõnede naabrite seas, kuid see on parem kui lasta tal hammustada.
Kas on huvitav selles suunas areneda? Registreeruge tasuta demo-tunniks ja osalege ülekanne , mille viib läbi Pavel Vikirjuk — MVNO sideoperaator, DevOps-insener.
Allikas: habr.com
