update/bdflush problem

Martin Mares mj na atrey.karlin.mff.cuni.cz
Pondělí Červenec 28 16:12:24 CEST 1997


Hello, world!

> S vasim zaverem nesouhlasim. Podle meho nazoru je v klasickem (= ne
> logovanem) filesystemu asynchronni zapis metadat velmi nebezpecny

   S vasim zaverem si pro zmenu dovoluji nesouhlasit ja -- zalezi ciste
na tom, jak je filesystem udelany. Napriklad se da navrhnout velice
slusny FS, ktery pouziva asynchronni zapis metadat, nicmene udrzuje
mezi nekterymi castmi metadat pevne poradi, takze po padu systemu
je FS recovery vice mene trivialni a ztrata dat nehrozi.

> a pri padu systemu se muzete dostat do stavu, kdy obnova urcitych
> dat bude fakticky nemozna, tedy alespon pokud nechcete po disku
> hledat jednotlive bloky dat a flastrovat disk pomoci fsdb nebo
> rovnou binarnim editorem.
> 
> Krome toho, ze muzete data ztratit, muze po padu padu systemu soubor
> byt ve stavu, ktery pracovne oznacuji jako "nebezpecne nekonzistentni,"
> zatimco rozumne si pocinajici fs driver muze pri synchronnim zapisu
> metadat zajistit, ze po padu bude stav "bezpecne nekonzistentni."

   I pri asynchronnim...

> P.S.: Urcite by se Vam libil advfs v DIGITAL UNIXu, ten vubec nema
> fsck... :-)

   To je podle mne zasadni chyba -- spolehat na spolehlivost FS se nemuze
vyplatit -- kdyby nic jineho, tak proto, ze ve FS mohou byt chyby, ci kvuli
nenadalym hardwarovym zavadam, ktere se tak stanou jen velice tezko
opravitelnymi. Na velice podobne chybne predpoklady o zarucene
konzistenci napriklad velice doplacel Amiga PFS Filesystem.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj na gts.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"We all live in a yellow subroutine."


Další informace o konferenci Linux