Vlákno názorů k článku AdvFS je otevřený, ale do Linuxu se zřejmě nedostane od Stanislav Brabec - Žurnálování je postup zápisu na disk, díky kterému...

Žurnálování je postup zápisu na disk, díky kterému máme v bezpečí data při problémech s nestabilními programy nebo při hardwarových problémech (například výpadek proudu nebo nestabilní komponenta).

To bohužel není pravda. Účelem žurnálu je rychlé obnovení konzistence souborového systému po nečekaném ukončení práce, za předpokladu předchozí bezchybné funkčnosti systému.

Žurnál nechrání data před nestabilními programy, to dokáže jedine snapshot.

Před nestabilním jádrem (a zvlášť implementací souborového systému a blokového zařízení) a před nestabilní komponentou neochrání data ani souborový systém nic!

Sám jsem zažil poničení souborového souborového systému při vadné paměti i při nestabilní implementací v testovací verzí jádra. Žurnál při tom vůbec nepomohl. Naopak, situaci zhoršil, neboť dokázal dlouho množící se chyby maskovat.

Já jsem se v článku asi špatně vyjádřil. Nestabilním programem jsem měl namysli program, který z nějakého důvodu zhavaruje uprostřed nějaké diskové operace. Při takovéto situaci by mělo žurnálovní samotných dat pomoci tím, že na disku nezůstanou nekonzistentní data. Ovšem ztráta dat v souboru, se kterými program pracoval, je v takovém případě pravděpodobná.

Zhavaruje-li program, data budou konzistentní i bez žurnálování. Žurnálování pomáhá pouze v případě havárie systému.

Nevím, jak funguje AdvFS, ale běžně se pod pojmen žurnálování rozumí pouze žurnálování metadat, které vlastní data vůbec nechrání. Po přehrání žurnálu mohou být v souborech, které byly v době havárie otevřené na zápis, nesmysly, které navíc nemusí odrážet jakýkoliv stav před havárií (tj. např. index k databázi se zapíše zatímco vlastní data se ztratí, přestože byla zapsána dřív).

Plné žurnálování včetně dat umí v Linuxu např. ext3.

To, co potřebuje enterprise nasazení, a co v Linuxu zatím skoro chybí, jsou atomické transakce, kdy je vždy zaručeno, že všechny soubory, se kterými aplikace pracovala, jsou po havárii buď v nedotčeném stavu, nebo s provedenou kompletní transakcí.

Jelikož je tato vlastnost implementačně podobná snapshotům, každý systém, který tyto funkce podporuje, je zajímavý.

Já měl za to, že reiserfs žurnáluje i data hned po vytvoření filesystému, ale už nevím jestli jsem to jen někde z něčeho neodvodil. Každopádně děkuji za doplnění informací.

Žurnálování dat je velmi drahá operace, alespoň u systémů, kde se na to nemyslelo rovnou při návrhu (znamená každý zápis provést jednou do žurnálu, pak podruhé do souboru, a poté provést výmaz ze žurnálu). Z běžných fs jí podporuje jen ext3 (při explicitní volbě "data=journal"). I tam je implicitně vypnutá, a používá se tam, kde je podstatná konzistence dat, i za cenu rychlosti.

V praxi ovšem ani žurnálování dat ke konzistenci dat nestačí, neboť dokončení jednotlivé zápisové operace nad FS nemusí znamenat dokončení atomické operace nad strukturou souboru (např. po provedení zápisu do souboru je nutné provést seek() a zapsat umístění právě zapsaných dat).

Tuto úroveň konzistence může nabídnout pouze implementace transakcí nad souborovým systémem - možnost, aby se všechny požadované změny v rámci jedné logické operace objevily ve struktuře FS na fyzickém médiu (disku) najednou. Například tak, že se celou dobu zapisují se speciální značkou pouze do žurnálu. Pokud je po havárii přehráván žurnál, operace, k jejichž značce chybí v žurnálu příznak dokončení, se anulují.

Samozřejmě, že toto vše lze implementovat i v uživatelském prostoru, ale je to méně efektivní.

ReiserFS 3 defaultně data nežurnáluje, ale dá se to pomocí data=journal zapnout. Reiser4 žurnáluje i data, jelikož díky jeho architektuře je to zadarmo.