Přeji všem skvélé víkendy! Zveme vás na bezplatnou ukázkovou hodinu , který povede Andrej Buranov – specialistka na UNIXové systémy ve společnosti Mail.Ru Group. Také publikujeme článek Jonathana Corbeta – výkonného redaktora ve LWN.net.
Žurnálové souborové systémy slibují osvobodit systémové administrátory od problémů s poškozením disku při selhání systému. I bez spuštění kontroly integrity souborového systému. I když ve skutečnosti je to samozřejmě trochu složitější. A jak ukazuje nedávná diskuse, může to být dokonce složitější, než si mnozí z nás myslí, protože zajištění integrity žurnálovaných souborových systémů ovlivňuje výkon.
Souborový systém jako ext3 používá oddělenou oblast na disku, nazývanou žurnál. Při provádění změn v metadatech souborového systému jsou tyto změny nejprve zapisovány do žurnálu, aniž by docházelo ke změnám v ostatních částech souborového systému. Po zapsání všech změn do žurnálu se do něj přidá „komitovací blok“, který znamená dokončení transakce. A pouze po zapsání komitovacího bloku je transakce zapsána, a změněná metadata jsou zapsána na disk. Pokud systém v nějakém okamžiku selže, pomocí informací v žurnálu lze bezpečně dokončit práci a předejít poškození souborového systému, protože byla aktualizována pouze část metadat.
Jak ale víme, existuje jeden zádrhel: kód souborového systému musí být před zápisem komitovacího bloku naprosto jistý, že všechny informace o transakci už se dostaly do žurnálu. Prostě zapisovat operace ve správném pořadí nestačí – moderní disky mají velké interní cache a přeskupují operace pro zlepšení výkonu. Proto je nutné před komitovacím blokem výslovně naznačit přesun všech dat žurnálu na disk. Pokud bude komitovací blok zapsán dříve, může být žurnál poškozen. K vyřešení tohoto problému se používají bariéry. V podstatě bariéra zakazuje zápis jakýchkoli bloků po bariéře, dokud nejsou všechny bloky zapsané před bariérou přeneseny na disk. Použitím bariér zajišťují souborové systémy konzistenci souborových struktur.
Ale existuje ještě jeden problém: souborové systémy ext3 a ext4 ve výchozím nastavení nepoužívají bariéry. Možnost existuje, ale pokud ji administrátor výslovně nezapnul, tyto souborové systémy fungují bez bariér, i když v některých distribucích (například SUSE) jsou výchozí hodnoty jiné. Eric Sandeen nedávno dospěl k názoru, že tuto situaci je třeba změnit a , který mění výchozí nastavení pro ext3 a ext4. A tehdy začala bouřlivá diskuse.
Andrew Morton velmi podrobně , proč je výchozí hodnota právě taková:
Když jsme se to minule pokusili změnit, výkonnost se u mnoha zátěží zhoršila o 30 %, takže jsem z děsu všechny tyto patche vyhodil. Myslím, že nemůžeme jít touto cestou a tak vážně zpomalit všechny stroje…
Není zde ideální řešení, a mířím k tomu, abych tuto spící psa nerušil a nechal výchozí parametry na úvaze vývojářů distribucí.
Takže ve výchozím nastavení jsou bariéry vypnuté, protože mají vážný vliv na výkon. Kromě toho se souborové systémy velmi úspěšně používají bez bariér. Zprávy o poškození souborového systému ext3 jsou vzácné a máločasté.
Ale to není jen štěstí. Ted Ts’o to tím, že žurnál ext3 / ext4 je obvykle umístěn kontinuálně. Za prvé, ovladač souborového systému se snaží vytvořit jej kontinuálně. Za druhé, žurnál se obvykle vytváří současně se souborovým systémem, kdy je snadné najít kontinuální prostor. Kontinuita a uspořádanost jsou užitečné nejen pro výkon, ale také pro zamezení přeuspořádání. Obvykle se blok potvrzení umístí hned za ostatní data v žurnálu, takže disk nemá důvod k přeuspořádání. Blok potvrzení se přirozeně zapisuje na disk ihned po ostatních záznamech žurnálu.
Nicméně nikdo netvrdí, že to tak bude vždy. Diskové jednotky se mohou chovat i jinak. Navíc deník funguje jako kruhový buffer. Když je transakce zapsána na konec deníku, může se commit blok nacházet v dřívějším bloku, před jinými záznamy deníku. Riziko poškození je tedy vždy přítomné. Ve skutečnosti má Chris Mason pro to . Není pochyb o tom, že práce bez bariér je méně bezpečná než s nimi.
Pokud jste připraveni na dopad na výkon, můžete zapnout bariéry. Samozřejmě pokud váš souborový systém není založen na LVM (jak tomu je v některých distribucích výchozí). Ukazuje se, že device mapper nepodporuje bariéry. V ostatních případech by bylo dobré minimalizovat pokles výkonu. A zdá se, že to lze udělat.
Současná implementace ext3 (když jsou bariéry zapnuté) provádí následující sekvenci operací pro každou transakci:
Data se zapisují do deníku
Provádí se bariéra
Zapisuje se commit blok
Provádí se další bariéra
Později jsou metadata zapsána na disk
Ve ext4 lze první bariéru (krok 2) opomenout, protože souborový systém ext4 podporuje kontrolní součty v deníku.
Pokud jsou data deníku a commit blok přeuspořádány a operace se přeruší v důsledku selhání, kontrolní součet deníku nebude odpovídat tomu, který je uložen v commit bloku, a transakce bude odmítnuta.
Chris Mason , že by bylo "z celkového hlediska bezpečné" odstranit tuto bariéru i v ext3, s možným vyloučením případu, kdy deník dosáhne konce a začne se znovu zapisovat od začátku.
Dalším nápadem na zrychlení práce je odložit operace s bariérami, kdykoli je to možné. Pokud není naléhavá potřeba okamžitě zapisovat data na disk, je možné vytvořit několik transakcí v deníku a zapsat na disk jednou bariérou.
Také existuje určitý potenciál pro zlepšení důkladným uspořádáním operací, aby bariéry (které jsou obvykle implementovány jako požadavky "zapsat všechny odložené operace na disk") nenutily zápis bloků, které nevyžadují uspořádání.
Zdá se, že přišel čas přemýšlet o tom, jak učinit náklady na bariéry přijatelnými. Ted Ts'o se zdá, :
Myslím, že bychom měli zahrnout bariéry do ext3/4 a poté pracovat na snížení režijních nákladů v ext4/jbd2. Pravděpodobně většina systémů nefunguje v podmínkách podobných těm, které použil Kris pro demonstraci problému, a bezpečnost souborového systému by měla být na prvním místě.
Zdravý rozum mi říká, že tenhle pes už nespí a pravděpodobně bude nějakou dobu štěkat. To může způsobit obavy některým sousedům, ale je to lepší než mu dovolit kousnout.
Zajímá vás rozvoj v tomto směru? Přihlaste se na bezplatnou demo lekci a účastněte se přenosu , který povede Pavel Vikiryuk — operátor MVNO, DevOps inženýr.
Zdroj: habr.com
