Dotaz: Jak žurnálování zajišťuje konzistenci dat?

[FrostyX]

Ahoj,
chtěl bych vás požádat o vysvětlení toho, jakým způsobem žurnálování zajišťuje konzistenci dat.
Podle skript žurnálování pracuje následovně (vynecháme-li cachování):

1. Informace o změně se zapíše do logu (žurnálu), přičemž se zapíší pouze metadata.
2. Změna se provede
3. Po úspěšném provedení je log vynulován

To je sice moc hezký, ale co konkrétně to teda přinese?

Dovedu si představit, že když dojde k nečekanému výpadku systému, při opětovném spuštění se může podívat do žurnálu, jestli nezůstali nějaké rozdělané operace. Tzn, lze během okamžiku zjistit, jestli je vše v pořádku, nebo ne. Ale co když ne? Napadlo mě, že jediné, co lze udělat, je nekompletní soubor nezobrazovat a prostě jej považovat, za prázdné místo.

Rozhodl jsem se experimentálně ověřit, co se na ext4 / NTFS stane. Dal jsem na NTFS svazek pod windows kopírovat velký soubor a v průběhu stroj natvrdo vypnul. Šlo ale o virtuální stroj ve VirtualBoxu - nevadí to? Po zapnutí jsem našel prostě rozepsaný soubor o zhruba poloviční velikosti. Tomu teda říkám konzistence. Na linuxu to dopadlo nějak podobně. Buď mi tam zůstal 0B soubor, nebo soubor o plné velikosti, nebo tak něco, ale prostě nešel otevřít.

Výsledky experimentu mi moc nepomohly, tak jsem na zkoušce zazmatkoval a řekl svůj původní názor. Vysloužil jsem si F a šel smutně domů.

Můžete mi prosím někdo vysvětlit, jak se to tedy s tím žurnálováním má?
Mockrát děkuji.

---

---

Odpovědi

[NN]

ext4 cast 'data mode' btw. jaky mas nastaveny typ?

[Filip Jirsák]

Nemůžete míchat obecný pojem „žurnálování“ a konkrétní implementaci v souborových systémech. Např. ext3/4 má samostatný žurnál pro metadata a samostatný pro data, přičemž ten datový žurnál je ve výchozím stavu vypnutý.

Jinak obecně žurnálování funguje tak, že se nejprve do žurnálu zapíše, co se má udělat, pak se to udělá, a pak se v žurnálu potvrdí, že se operace provedla. Takže když dojde k výpadku při zápisu do žurnálu, nemá zapisující potvrzen zápis a měl by se podle toho chovat. Když je vše zapsáno v žurnálu, potvrdí se zápis a od toho okamžiku už je starostí souborového systému, aby o ta data nepřišel. Začne provádět tu operaci – a pokud v tom okamžiku dojde k výpadku, po obnovení provozu jenom znova provede to, co má v žurnálu označené jako neprovedené.

Pokud byste tedy měl zapnutý i žurnál na data (a ta aplikace ten soubor kopírovala správně, tj. jako transakci označila kopírování celého souboru, ne jeho části), zapsal by se nejprve celý do žurnálu a teprve z něj by se pak kopíroval na cílové místo. Záleží na konkrétní implementaci, ale v nejjednodušším případě to znamená, že potřebujete na disku tolik místa, aby se tam ten soubor vešel dvakrát, a musíte ho dvakrát zapsat na disk – už je vám asi jasné, proč je ve výchozím nastavení v ext3/4 žurnál pro data vypnutý.

[R]

Este doplnim, ext3/4 pouziva defaultne mod data=ordered, co by malo zabezpecit (ak to neposerie "inteligentny" HW), ze najprv sa zapisuju data a az nasledne metadata. Tym padom by v subore, ktory sa zapisoval pocas vypadku, nemali byt nezmyselne data.

[Bill Gates]

Jen polemika:

v nejjednodušším případě to znamená

Me prijde nejjednodussi ten soubor zapsat uz skoro primo na misto tam kde v budoucnu bude, defaultne jako neplatny, a pak ho oznacit jako za platny (zapis). Bez nutnosti (zapis/cteni/zapis). Pak vlastne menime prinejmensim jeden bit nekde misto prepisu velkeho objemu dat.

[Sten]

Takhle jednoduše funguje btrfs. Při implementaci velmi rychle zjistíte, že to moc jednoduché není (např. co budete dělat, pokud vypadne proud během toho přepisu? ztratíte původní data? pokud budete mít dvě sady dat, při změně pár bajtů budete kopírovat celý soubor? co když proud vypadne, když zrovna budete přehazovat jednu sadu za druhou?) a žurnál je mnohem jednodušší.

[Heron]

Mě tedy mnohem jednoduší přijde to co implementuje btrfs, tedy cow po blocích.

Zapisujete na na nové místo bloku a jakmile je blok zapsaný, tak atomicky přepíšete pointer z původního bloku na tento nový.

Tedy kopíruje se nikoliv celý soubor ale jen dotčený blok a v případě výpadku máte buď konzistentní stará data (pointer se nepřehodil) nebo konzistentní nová data (pointer se přehodil), ale nic mezi tím.

Toto se ostatně v IT používalo od pradávna, nikoliv však pro fs. U fs se muselo udělat snoubení mezi B-tree a cow.

Jinak by mě zajímalo, za co přesně tazatel dostal F a zejména na co se ho zkoušející ptal. Protože otázka "jak žurnálování zajištuje konzistenci" je široká a asi nejlepší odpověď je: různě. Implementace se liší stejně, jako se liší jednotlivé fs.

[Sten]

tak atomicky přepíšete pointer z původního bloku na tento nový

Jenže na blokových zařízeních atomické operace nejsou.

Toto se ostatně v IT používalo od pradávna

Pouze tam, kde atomické operace jsou.

[FrostyX]

Děkuji za obsáhlou odpověď. O žurnálování včetně kompletních dat jsem nevěděl. Z vašeho vysvětlení jsem ho pochopil, takže děkuji. Nicméně,

Začne provádět tu operaci – a pokud v tom okamžiku dojde k výpadku, po obnovení provozu jenom znova provede to, co má v žurnálu označené jako neprovedené.

Tohle je právě věc, které nerozumím. Nebo alespoň v případě, kdy nedochází k žurnálování dat jako takových, ale pouze metadat. On ví, že měl vytvořit soubor nějakého názvu a velikosti, s nějakými oprávněními, vlastníkem, etc a že do něj měly přijít nějaká data. Ale jaká data to jsou, to už z toho žurnálu nevyčte ne? Co tedy znamená "znova provede"?

[FrostyX]

A nebo do toho žurnálu dává i nějakou posloupnost bytů, co do toho souboru bude zapisovat? A potom co ji uloží na disk, vynuluje žurnál a zapíše tam novou operaci uložení daných bytů. Takže při obnovení provozu jen na disk uloží tu poslední posloupnost bytů, o které z žurnálu ví a tím končí.

[Sten]

„Provést znovu“ je dost zjednodušené. Žurnál popisuje, co souborový systém právě dělá, a pokud dojde k problémům, ví tak, kde skončil. Pokud jsou v žurnálu data, stačí tu operaci opravdu jen provést znovu, ale pokud ta data nemá, tak se souborový systém jen pokusí dostat soubor do nějakého konzistentního stavu, typicky tak, že alokované místo, kam se zatím data nezapsala, ze souboru odebere, takže neobsahuje bloky s náhodnými (či nulovými) daty. Samozřejmě to znamená, že při nějaké složitější operaci může být soubor vnitřně poškozen, proto si třeba databáze vedou žurnál svých operací ještě samy bokem (a nejlépe vůbec nepoužívají souborový systém), ale pro běžné operace, kdy se zapisují data jen na konec (stahování, kopírování ap.), to dostane soubor do stavu, kdy lze operaci bezpečně navázat a nemusí se to celé dělat znovu.

[Filip Jirsák]

Pokud se zapisují nejprve data, a až poté metadata, nemělo by k něčemu takovému dojít. Data se sice zapsala do alokovaného místa, ale v metadatech o tom není záznam, takže ve výsledku je jen jiné „smetí“ v nepoužívané části disku.

Tomu vnitřnímu poškození předchází spousta programů (hlavně těch ze světa Windows) tak, že zapíší soubor s novým jménem, a pak jej přejmenují na původní název. A pak se uživatelé nestačí divit, že z toho souboru mizí práva (ACL) a že přestávají fungovat hardlinky.

[Sten]

Vždyť píšu, že se to týká případu, kdy data v žurnálu nejsou

[Filip Jirsák]

Já jsem psal o případu, kdy data v žurnálu nejsou, a přesto se po výpadku neprovádí odebírání místa, kam se data nezapsala - protože takové místo nevznikne.

Žurnál obvykle funguje tak, že jde v čase pouze dopředu, tj. jsou v něm zapsané akce, které se mají provést, a nikdy se akce neruší. Vámi popsaný způsob implementace, kdy žurnál popisuje nějaký stav, do kterého se má systém po výpadku vrátit, je sice také možný, ale je mnohem komplikovanější. Třeba zpětné smazání zapsaných dat je ještě relativně jednoduché, ale opačná operace - zápis vymazaných dat, by byla mnohem komplikovanější. Mimo jiné i proto, že byste při mazání musel data přesouvat do žurnálu, aby bylo odkud je v případě výpadku obnovit.

[Filip Jirsák]

On ví, že měl vytvořit soubor nějakého názvu a velikosti, s nějakými oprávněními, vlastníkem, etc a že do něj měly přijít nějaká data.

Souborový systém nedostane příkaz „vytvořit soubor a zapsat do něj data“. Ten příkaz zápisu dat je samostatný, a interně se provedou dvě operace – zápis samotných dat, a změna metadat souborového systému (změna velikosti souboru, změna prázdného místa na souborovém systému). Ten zápis dat se ve výchozím nastavení provede bez žurnálu, tj. data se hned přepíšou. Když uprostřed zápisu vypadne proud, budete mít v souboru půlku nových dat a půlku starých (v ext3/4, které přepisují data na místě). Žurnáluje se pouze zápis metadat – tj. do žurnálu se zapíše, jak se změnila velikost souboru a volné místo na disku, a pokud pak během zápisu údajů na správná místa na disku dojde k výpadku, po obnovení se pouze znovu přehraje žurnál s metadaty a ty údaje se obnoví. Nebo-li při náhlém výpadku můžete přijít o data (přepsal se kus starých dat novými, nebo se nová data zapsala na volné místo, ale ještě se nestihly aktualizovat metadata), ale souborový systém zůstane konzistentní. Bez žurnálování metadat se může dostat souborový systém do nekonzistentního stavu – např. se stihne zapsat změna velikosti souboru, ale už se nestihne zapsat údaj o volném místu. Proto se pak po obnovení musí projít celý disk a uvést jej do konzistentního stavu. To je asi hlavní důvod, proč se v ext3 žurnál zavedl – disky už jsou tak velké, že jejich kontrola po neočekávaném výpadku trvá příliš dlouho. Pokud máte žurnál na metadatech, není ta kontrola nutná – a na druhou stranu metadat není tolik, aby režie s žurnálováním spojená nějak výrazně zpomalovala práci. Žurnálováním dat byste samozřejmě získal vyšší spolehlivost (v souboru byste měl buď stará data, nebo nová, ale ne jejich mix), ale za cenu zpomalení zápisu na disk. Žurnál dat se tak používá jenom tam, kde je opravdu potřeba – typicky databáze, které si tradičně žurnál řeší samy. I když je pravda, že moderní souborové systémy (ZFS, btrfs), které umožňují vytvářet snapshoty a podobné vylomeniny, mají už žurnál i na datech, protože bez toho by těch nových vlastností nebylo možné dosáhnout.

[FrostyX]

Děkuji za vysvětlení. Vaše odpovědi označuji jako řešení.

[Sten]

brtfs ani ZFS nemají žurnál vůbec, používají COW, kdy se veškeré změny dělají stranou a pak se „jen“ přehodí odkaz (není to tak jednoduché, jinak by se to používalo už dávno). Díky tomu je jejich strom souborů vždy v konzistentním stavu (buď obsahuje stav před změnou nebo stav po změně, bez ohledu na to, kdy vypadne proud) a jako bonus to umí snapshoty, reflinky a vyšší životnost na SSD discích.

[chrono]

O tej vyššej životnosti SSD diskov pochybujem (pretože takmer určite bude na takom disku viac dát, ako pri iných FS a firmware disku sa aj tak sám stará o to, aby sa sektory využívali rovnomerne).

[Josef Kufner]

Ono jde spíš o to, jak moc se musí přepisovat ostatní bloky při přepisu. To SSD si to přemapuje, aby se neopotřebovávalo příliš, ale při zápisu nového souboru může odpadnou starost o malý sousední soubor.

Dat tam více nebude trvale, to jen do doby, než se bloky použité starým souborem označí jako volné (viz trim/discard).

[R]

Vyskusaj si to takto: daj si stahovat subor z webu a v polovici resetuj PC. Vo Windows 98 (FAT) sa ti spusti kontrola filesystemu a ten subor bude v prdeli, mozno aj s niecim dalsim. Na ext3 sa len pri dalsom mounte len prehra zurnal a subor bude obsahovat zmysluplne data, takze mozes pokracovat v stahovani.

[FrostyX]

Smysluplné ano, nejspíš tam bude prostě ta stažená část souboru. Takže pokud to bude video, podaří se mi ho do půlky přehrát a pak se ukončí. A to znamená, že jsou konzistentní? Možná jsem si jenom špatně vykládal to slovo. Moje představa byla taková, že ty data jsou konzistentní pouze v případě, že se na disk uloží přesně to, co jsem původně chtěl (celé video). Tzn pokud odpovídá checksum zdrojového a cílového souboru.

[NN]

Konzistentni znamena, ze neobsahuje chyby. To, ze se kopirovani prerusilo v pulce je smula..

[FrostyX]

Aha. Takže jsem v tom vlastně hledal něco úplně jiného

[Pepa]

Tak to používej XFS, tam při výpadku budeš mít konzistentně nulové soubory. Přesně podle tvé představy, buď nic nebo vše. Ale fakt to nechceš

[FrostyX]

Ne, to opravdu nechci. Jen mi šlo o pochopení principů toho žurnálování.