Soovin kõigile head nädalavahetust! Kutsume tasuta demotunnile , mida viib läbi Andrei Burannov — UNIX-süsteemide spetsialist Mail.Ru Groupis. Samuti avaldame Jonathan Corbet'i artikli — LWN.net'i toimetaja.
Ajaloos salvestavad failisysteemid lubavad süsteemiadministraatoreid vabastada ketta kahjustumise probleemidest süsteemi tõrgete korral. Isegi ilma failisüsteemi terviklikkuse kontrollimise käivitamiseta. Kuigi tegelikkuses on kõik veidi keerulisem. Ja nagu näitab hiljutine arutelu, võib see olla isegi segasem, kui paljud meist arvavad, kuna ajaloos salvestavate failisüsteemide terviklikkuse tagamine mõjutab jõudlust.
Failisüsteem, nagu ext3, kasutab kettal eraldi ala, mida nimetatakse ajakohanduseks. Kui failisüsteemi metaandmetes tehakse muudatusi, salvestatakse need muutused esmalt ajakohandusse, ilma et ülejäänud failisüsteemi muudetaks. Pärast kõigi muudatuste salvestamist ajakohandusse lisatakse sinna „commit block”, mis näitab tehingu lõpetamist. Ja ainult pärast commit blocki salvestamist fikseeritakse tehing ning muudetud metaandmed kirjutatakse kettale. Kui süsteem mingil hetkel rikki läheb, saab ajakohanduses oleva info abil turvaliselt töö lõpetada ja vältida failisüsteemi kahjustusi, kuna värskendati ainult osa metaandmetest.
Kuid on üks koer maas: failisüsteemi kood peab enne ploki commiti kirjutamist olema täiesti kindel, et kogu teave tehingu kohta on juba ajakirja jõudnud. Lihtsalt õige järjekorras opsioonide salvestamine ei ole piisav — kaasaegsed kettad toetavad suuri sisemisi vahemälusid ja ümberkorraldavad operatsioone jõudluse parandamiseks. Seetõttu tuleb ploki commiti enne selgelt näidata, et kõik ajakirja andmed on kettale edastatud. Kui ploki commit kirjutatakse varem, võib ajakiri kahjustuda. Selle probleemi lahendamiseks kasutatakse tõkkeid. Tõkked keelavad põhimõtteliselt pärast tõket kirjutada mis tahes plokke, kuni kõik tõkke eelnevalt kirjutatud plokid on kettale edastatud. Tõkkeid kasutades tagavad failisüsteemid faili struktuuride järjepidevuse.
Kuid on veel üks probleem: ext3 ja ext4 failisüsteemid ei kasuta vaikimisi barjäärisid. Valik on olemas, kuid kui administraator ei lülita neid selgesõnaliselt sisse, siis töötavad need failisüsteemid ilma barjäärideta, kuigi mõnes jaotuses (näiteks SUSE) on vaikimisi väärtused teistsugused. Eric Sandeen otsustas hiljuti, et seda olukorda tuleb muuta ja , mis muudab vaikimisi seadistusi ext3 ja ext4 jaoks. Ja siis algas elav arutelu.
Andrew Morton , miks vaikimisi väärtus on just selline:
Eelmisel korral, kui me proovime seda muuta, halvenes paljude koormuste korral jõudlus 30%, seetõttu viskasin ma kõik need patšid kohkunult minema. Ma arvan, et me ei saa sellele minna ja aeglustada kõiki masinad nii tõsiselt ...
Siin pole ideaalset lahendust ja ma kaldun arvama, et ei tasu seda uinuvaid koera äratada ja jätta vaikimisi seaded jaotuste arendajate otsustada.
Seega on vaikeed vaikimisi välja lülitatud, kuna need mõjutavad tõsiselt jõudlust. Lisaks kasutatakse failisüsteeme edukalt ka ilma barjäärideta. ext3 failisüsteemi kahjustuse teateid on üsna harva ja need on haruldased.
Aga see ei ole lihtsalt vedamine. Ted Ts’o seda, et ext3 / ext4 ajalugu on tavaliselt pidevalt paigutatud. Esiteks, failisüsteemi draiver püüab seda luua pidevana. Teiseks luuakse ajalugu tavaliselt koos failisüsteemiga, kui on lihtne leida pidevat ruumi. Jätkuvus ja järjestus on kasulikud mitte ainult jõudluse, vaid ka uuesti järjestuse tõkestamise jaoks. Tüüpiline commit block paigutatakse kohe pärast muid andmeid ajaloos, nii et kettal ei ole põhjust uuesti järjestuse leidmiseks. Commit block kirjutatakse loomulikult kettale kohe pärast muid ajaloos olevaid kandeid.
Kuid keegi ei väida, et see alati nii jääb. Kõvakettad võivad käituda teisiti. Lisaks on žurnal ringbuffer. Seega, kui tehing kirjutatakse žurnali lõppu, võib commit block sattuda varasemasse blokki, enne muid žurnali kirjeid. Seega on kahjustamise oht alati olemas. Tegelikult on Chris Masonil selle kohta . Pole kahtlust, et barjääridega töötamine on vähem turvaline kui nende puudumine.
Kui olete valmis suutma jõudluse kahjustust, siis võite barjäärid sisse lülitada. Kuid ainult juhul, kui teie failisüsteem ei põhine LVM-il (nagu mõnes jaotuses vaikimisi). Tundub, et seadme kaardistaja ei toeta barjääre. Muudel juhtudel oleks hea vähendada jõudluse langust. Ja näib, et seda on võimalik teha.
Praegune ext3 rakendus (kui barjäärid on sisse lülitatud) täidab iga tehingu jaoks järgmised toimingud:
Andmed kirjutatakse žurnali
Teostatakse barjäär
Kirjutatakse commit block
Teostatakse järgmine barjäär
Hiljem kirjutatakse metaandmed kettale
ext4 failusüsteemis saab esimesest takistuspunktist (samm 2) loobuda, kuna ext4 toetab ajakirjade kontrollsummasid.
Kui ajakirja andmed ja commiti plokk on ümber korraldatud ning operatsioon katkestatakse tõrke tõttu, siis ajakirja kontrollsumma ei vasta sellele, mis on salvestatud commiti plokis, ja tehingut ei aktsepteerita.
Chris Mason , mis tähendaks, et oleks „üldiselt ohutu“ sellest takistuspunktist loobuda ka ext3 puhul, välja arvatud juhul, kui ajakiri jõuab lõpuni ja hakkab uuesti kirjutama algusest.
Veel üks idee, et suurendada toimivust, on takistuste opereerimise edasi lükkamine, kui see on võimalik. Kui andmete kohe kettale kirjutamine ei ole hädavajalik, siis võidakse ajakirjas luua mitu tehingut ja need kettale ühe takistusega kirjutada.
Samuti on teatav potentsiaal parendamiseks põhjaliku operatsioonide järjekorra korralduses, et takistused (mida tavaliselt rakendatakse kui „kõik oodatud operatsioonid kettale kirjutada“) ei sunniks kirjutama plokke, mis ei nõua järjekorrastamist.
Tundub, et on aeg mõelda, kuidas muuta takistuste maksumus vastuvõetavaks. Ted Ts'o paistab olevat :
Ma arvan, et peaksime ext3/4 sisse panema barjäärid ja seejärel töötama ext4/jbd2 ülehead kulude vähendamise nimel. Tõenäoliselt ei tööta enamik süsteeme tingimustes, nagu Chris kasutas probleemi demonstreerimiseks, ja faili süsteemi turvalisus peaks olema prioriteet.
Mulle ütleb terve mõistus, et see koer ei maga enam ja tõenäoliselt hakkab ta mõnda aega häält tegema. See võib tekitada mõningate naabrite seas muret, kuid see on parem kui lasta tal hammustada.
Kas oled huvitatud selle valdkonna arengust? Registreeru tasuta Demo-tundi ja osale ülekandes , mida viib läbi Pavel Vikirjuk — MVNO kommunikatsioonispetsialist, DevOps-insener.
Allikas: habr.com
