Zurnalovaci FS

[Martin Machacek]

On 25-Jul-00 Petr Holub wrote:
> Pokud je mi znamo, tak na vsech BSD unixech je FFS, ktery je
> od prirody zurnalovaci se vsim vsudy.

Ne, ne to neni v zadnem pripade pravda. FFS je STAVOVY filesystem a ne
zurnalovy. NENI, nikdy nebyl a nikdy nebude. Viz:

/usr/share/doc/smm/05.fastfs/paper.ascii.gz (instaluje se v defaultni instalaci
FreeBSD)

Nicmene, jiz vice nez rok je pro FFS k dispozici vylepseni, ktere se jmenuje
SOFTUPDATES. Detaily je mozne najit na:

http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.html

Na FreeBSD 4.0-STABLE a novejsich je mozne SOFTUPDATES povolit zkompilovanim
noveho jadra s "option SOFTUPDATES" a aplikovanim "tunefs -n enable" na vsechny
filesystemy, kde se maji SOFTUPDATES pouzivat (filesystem musi byt pri
modifikaci odmontovany - root muze byt namontovany readonly). 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). Jinak
SOFTUPDATES jsou standardni soucasti distribuce FreeBSD od verze 3.0.
SOFTUPDATES umoznuji provadet i zapisy metadat (inodu) asynchronne. Bez
SOFTUPDATES se zapisy dat (vlastni obsah souboru) provadi asynchronne (kdyz je
zrovna cas) a zapisy metadat se provadeji synchronne (tedy system ceka na to,
nez disk resp. radic potvrdi, ze data jsou zapsana). SOFTUPDATES provadeji
castecne prerovnavani zapisu tak, aby v kazdem okamziku v pripade havarie
systemu, vypadku napajeni atd., 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. Dalsi vyhodou SOFTUPATES je to, ze
umoznuje nektere redundantni operace s metadaty vynechat. Napr. pokud se maze
adresarovy strom, je zbytecne zapisovat zmeny do adresaru, ktere stejne v zapeti
prijdou zrusit. SOFTUPDATES pri pridavani noveho pozadavku na zapis dat nebo
metadat do fronty kontroluje zda nektery z predchozich pozadavku se tim nestava
zbytecny. Obzvlaste v pripade mazani adresarovych stromu je rozdil ve vykonnosti
opravdu vyznamny a FFS se SOFTUPDATES je rychlejsi nez kompletne asynchronni
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 (osobne jsem videl situaci, kdy uprostred
/etc/passwd jsem mel kousek /usr/bin/passwd a  fsck tvrdilo, ze filesystem je
OK). 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.

> Schvalne jsem si tohle se svym FreeBSD strojem zkousel (2x14 GB disky + 50 GB
> SW diskove pole - vinum) tak, ze jsem ho z niceho nic vypnul, kdyz makal
> a fsck pri bootu trval asi 3 min (uz si to uplne presne nepamatuju).

Rychlost fsck zavisi nejvice rychlosti IO systemu, dale na velikosti operacni
pameti a trochu i na vykonnosti procesoru. Pokud ma system rychle disky, hodne
pameti a vykonny procesor, muze byt fsck i pomerne rozsahleho diskoveho prostoru
rychle. Takze rychly fsck po havarii systemu nemuze byt dukazem toho, ze FFS je
zurnalovy filesystem ;-). To opravdu neni, ale  to nevadi, protoze se
SOFTUPDATES je srovnatelne rychly s zurnalovymy filesystemy a i cas nezbytny na
kontrolu konzistence filesystemu po havarii je "rozumny". Viz:

http://www.usenix.org/publications/library/proceedings/usenix2000/general/seltze
r.html


Jinka, pokud vim, tak v OpenSource svete neni pro BSD  k dispozici zadny
opravdu pouzitelny zurnalovy filesystem. LFS, ktere bylo dlouho dobu
distribuovano i s FreeBSD nebylo nikdy uplne dokoncene.


        Martin 

---
[PGP KeyID F3F409C4]