Zurnalovaci FS

[Cejka Rudolf]

Doufam, ze to muzu jeste trochu doplnit. Nemam rad,
kdyz se vsude mluvi jen o zurnalovani :-)

Na tema zurnalovacich FS (JFS), log-structured FS (LFS) a
softupdates (SU) se snapshoty (SS - ziskani zmrazeneho stavu FS)
se daji psat hodne dlouhe romany (a to jeste nezminuji [JL]FS
s podporou HW). Ja osobne verim mnohem vice SU se SS nez [JL]FS,
ale objektivni hodnoceni prinese pouze cas. Pokud se tedy setkate
s nekym, kdo bude tvrde prosazovat [JL]FS, hned se ho zeptejte na
SU - a pokud o nich nebude nic vedet, s usmevem mu vysvetlete, ze
ponekud zaspal dobu (priblizne sest roku - nekdy v te dobe byla
myslenka SU poprve zverejnena).

O co tady jde:

1) Vysoka rychlost: SU prakticky dosahuji rychlosti plne asynchronniho
   (tj. velmi nebezpecneho) zapisu - nekdy jsou trochu lepsi a nekdy
   trochu horsi. Podle vysledku, ktere jsem zatim videl, [JL]FS jsou
   vzdy pomalejsi - nekdy o par procent, nekdy velmi vyrazne
   (hlavne pri mazani souboru?)

2) Zajisteni co nejvetsi konzistence FS pri vypadku a zajisteni
   co nejkratsi doby restartu systemu: SU umoznuji start systemu i
   bez fsck. Opravu nekonzistenci lze teoreticky provadet i na zivem
   FS, ale v praxi McKusick asi skonci s fsck pomoci SS. To sice bude
   znamenat delsi dobu provadeni fsck, ale i tak by fsck pomoci SS melo
   byt mnohem kratsi, nez fsck na klasickych FS, protoze diky SU staci
   kontrolovat mene veci. Navic fsck pujde spustit kdykoli a navic
   v pozadi na zivem fs, takze by to nemel byt zadny problem. Bohuzel
   zatim existuje pouze prvni verze snapshotu v -currentu a na fsck na
   pozadi si musime jeste nejakou dobu pockat. [JL]FS opravu konzistence
   vyzaduji. Doba opravy muze byt velmi kratka, ale i podobna jako na
   klasickych FS - zde hodne zavisi na konkretni implementaci.

3) Moznost zalohovani na zivem FS: Hlavnim problemem je vytvoreni
   konzistentniho obrazu FS v dany casovy okamzik. Vlastni zaloha
   se pak provadi klasickym zpusobem. U [JL]FS vytvoreni konzistentniho
   obrazu FS vetsinou byva jednoduche. Jen je potreba si nejdrive overit,
   zda to ma uvazovany [JL]FS implementovano ;-) O SS McKusick napsal,
   ze implementace se ukazala byt primocara. Dodal uz i prvni informace
   o rychlosti: U 8 GB FS mu vytvoreni SS trva priblizne 30 sekund
   (z toho 25 sekund je priprava a na 5 sekund se zmrazi zapisove
   operace na FS za ucelem okopirovani konzistentniho stavu). Je
   dovoleno mit az 20 ruznych SS pro kazdy FS, ktere pak lze kamkoli
   pripojit do adresaroveho stromu - to mi pripada hodne zajimave.

Martin Machacek wrote (2000/07/25):
> Na FreeBSD 4.0-STABLE a novejsich je mozne SOFTUPDATES povolit zkompilovanim
> noveho jadra s "option SOFTUPDATES"...

A od FreeBSD 4.1 jiz budou SU soucasti standardniho jadra GENERIC
(takze SU lze povazovat za stabilni).

> U starsich FreeBSD bylo pred kompilaci jadra jeste nezbytne vytvorit
> dva symlinky v adresari /usr/src/sys/ufs/ffs (viz README.softupdates
> v tomto adresari).

A kdo aktualizuje system pres CVSup a tyto symlinky si vytvoril, musi
je nyni zase rucne zrusit (!), protoze diky zmene na licenci BSD mohly
byt soubory presunuty na misto symlinku - a CVSup nahrazeni symlinku
za soubory neudela.

> SOFTUPDATES provadeji castecne prerovnavani zapisu tak...

Jo "castecne" :-) Ja ten paper cetl - a takhle slabe slovo bych
teda napsat nedokazal :-) Mozna "castecne", ale "silenym zpusobem" :-)

> ... byl vzdy na disku v nejhorsim pripade detekovatelne nekozistentni
> stav. To znamena, ze je zarucene, ze fsck po bootu bude umet
> nekonzistenci najit a pripadne i opravit. V 99% pripadu je na disku
> konzistenti stav, takze fsck nema moc prace.

U SU mohou vzniknout pouze tyto nekonzistence:
  1) Volne datove bloky mohou byt v bitmape bloku oznacene jako obsazene.
  2) V i-uzlech moze byt vyssi pocet odkazu, nez ve skutecnosti.
Fsck pro SU tedy muze resit pouze tyto problemy. Ale pokud vypadek
nastane napriklad v dobe "rm -r *", oprav bude urcite vic, nez
v pripade standardniho zapisu meta-sync-data-async.

> filesystemy jako je napr. Linuxovy ext2fs. Ten dela (defaultne) zapisy dat i
> metadat asynchronne a tudiz obecne nezarucuje, ze po havarii systemu
> bude fsck schopne detekovat pripadnou nekonzistenci a tak se muze
> klidne stat, ze dojde napr. ke spojeni dvou souboru...

:-) Skoro by se mi chtelo napsat, ze to "... obecne zarucuje, ze fsck
nebude schopne..." :-)

> Dochazi k tomu, ale pouze velmi zridka a to predevsim na systemech, ktere
> provadeji hodne operaci s metadaty (tedy vytvareji a rusi hodne souboru)
> jako jsou napr. mailservery nebo newsservery.

A v linuxove konferenci se o tezce ponicenych FS
psalo hlavne v souvislosti v bezicim mrtg.

> Rychlost fsck zavisi nejvice rychlosti IO systemu, dale na velikosti
> operacni pameti a trochu i na vykonnosti procesoru.

A dale na obsazenosti FS (na poctu obsazenych i-uzlu a na poctu
obsazenych datovych bloku).

-- 
Rudolf Cejka   (cejkar at dcse.fee.vutbr.cz;  http://www.fee.vutbr.cz/~cejkar)
Brno University of Technology, Faculty of El. Engineering and Comp. Science
Bozetechova 2, 612 66  Brno, Czech Republic