update/bdflush problem

[Alexandr Malusek]

> 	Synchronni zapis metadat nema vliv na bezpecnost/konzistenci
> dat na filesystemu, je-li zapis dat asynchronni a bez journalingu.
> ...

Nerad bych do toho prilis stoural, protoze se rozhodne nepovazuji za
odbornika v teto oblasti, ale synchronni zapis metadat byl v s5fs a
nsledne v FFS filesystemech (tam patri i Solarisi ufs) zaveden proto,
aby se zajistilo, ze metadata jsou zapisovana v urcitem poradi. To se,
myslim, pri asynchronnich zapisech zajistit neda (Abych pravdu rekl,
tak nevim, jak jsou tyto veci v praxi u synchronnich zapisu reseny,
protoze moderni SCSI disky umoznuji samy preorganizovavat poradi
zapisu). Vetsinou se uvadi nasledujici priklad:

Pri vymazani souboru se nejprve vymaze polozka v adresari, pak inode,
pak se uvolni diskove bloky. Pokud by se nejprve uvolnil inode, a
doslo by k padu systemu, pak by polozka adresare ukazovala na
nealokovany inode (nebo jiz dokonce na inode alokovany jinym souborem).

Pokud se to dela ve spravnem poradi, pak se s tim fsck snaze vyporada.

Samozrejme je pravda, ze synchronni zapisy (dat i metadat) nezaruci
konzistentni filesystem. Spis snizuji pravdepodobnost jeho vaznejsiho
poskozeni. Otazkou je, jestli se to vyplati. Pokud jsem to spravne
pochopil, tak vyvojari ext2fs dali prednost asynchronnimu zapisu
metadat, zatimco vyvojari FFS synchronnimu (aspon u nekterych
metadat).  To je zrejme ten duvod, proc jsou operace s adresari na
Solarisim ufs filesystemu tak vyrazne pomalejsi oproti ext2fs.

Celkem hezky popis koncepci ruznych filesystemu je v knize
Uresh Vahalia, UNIX Internals, Prentice Hall.

S pozdravem,
Alexandr Malusek (malusek na ujf.cas.cz)
UJF AV CR