update/bdflush problem

[Jan Kasprzak]

	Jeste jednou se vratim k problemu reliability souboroveho systemu
a pokusim se obhajit sve tvrzeni:

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

Alexandr Malusek:
: 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.

	fsck se vyporada s obema vyse zminenymi pripady (v jednom pripade
nalinkovani souboru do /lost+found a ve druhem prostym zvetsenim poctu odkazu
v i-uzlu; navic ext2 eviduje cas zruseni i-uzlu -- dtime, coz fsck muze
pomoci s odhadnutim, je-li i-uzel smazan, nebo ne).

: Samozrejme je pravda, ze synchronni zapisy (dat i metadat) nezaruci
: konzistentni filesystem. Spis snizuji pravdepodobnost jeho vaznejsiho
: poskozeni.

	Tohle neni pravda: Problem zustava (a u asynchronniho zapisu
metadat je dokonce mensi, protoze cas mezi zapisem metadat a vlastnich dat
-- kdy je FS nekonzistentni -- se minimalizuje, zatimco u synchronniho
zapisu metadat je mezi zapisem metadat a vlastnich dat az 30 sekund).

: Pokud jsem to spravne
: pochopil, tak vyvojari ext2fs dali prednost asynchronnimu zapisu
: metadat, zatimco vyvojari FFS synchronnimu

	Jak BSD FFS, tak ext2 umoznuji i synchronni i asynchronni zapis
metadat volitelne. Jak ale tvrdim asynchronni zapis metadat nesnizuje
reliabilitu FS (a v nekterych pripadech ji zvysuje).

: To je zrejme ten duvod, proc jsou operace s adresari na
: Solarisim ufs filesystemu tak vyrazne pomalejsi oproti ext2fs.

	Myslim, ze jen castecne: Ext2fs ma trochu lepe organizovany
adresar.
 
Eduard Vopicka:
: S vasim zaverem nesouhlasim. Podle meho nazoru je v klasickem (= ne
: logovanem) filesystemu asynchronni zapis metadat velmi nebezpecny
: 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."

	OK. Pomineme tedy moznost ztraty dat az do intervalu 30 sekund (tohle
nezavisi na metadatech) a uvazujme jen to, do jake nekonzistence
se jednotlive FS mohou dostat.

	Premyslel jsem dlouho, ale vyloucim-li vypadek proudu uvnitr
zapisu jednoho sektoru (a tim poskozeni napr. tabulky i-uzlu),
nemuzu najit pripad, ktery by fsck nebyl schopen zvladnout.

	U asynchronniho zapisu metadat muze nastat pripad zmineny panem
Maluskem -- adresar ukazujici na volny nebo jemu nepatrici i-uzel,
u synchronniho zase muze nastat pripad soubor obsahujici bloky, ktere
pred nedavnem patrily jinemu souboru. S tim, ze pri asynchronnim zapisu
dat by musel vypadek nastat behem jednoho pruchodu hlavicky nad diskem
(cca sekundy), zatimco u synchronniho tento nebezpecny interval trva
v prumeru 15 vterin.

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

	advfs je zajimava vec (zejmena klonovani FS se mi libi),
ale: 1) nechci videt, jak slozite je to naprogramovane -- kernel Digital UNIXu
ma 4-8 MB a 2) advfs musi mit nejakou moznost zotaveni se napriklad
z HW chyb ==> neco jako fsck musi byt ve vlastnim FS driveru, to jest
v kernelu. Fuj! Priste si dam do kernelu X server a Netscape :-)

	Z tohoto hlediska je zajimavy tez SGI xfs -- tento system
ma mj. i sluzbu quality of service -- muzete si napriklad rict,
ze pozadujete minimalni garantovanou cteci rychlost 0.5 MB/s a ostatni
procesy jsou pak systemem omezeny tak, ze tuto rychlost vzdy dostanete.
Jednim z vyvojaru XFS je Larry McVoy, autor benchmarku lmbench.

Martin Mares:
[...]
: 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.

	Ano, Martin ma pravdu. Otazkou neni synchronni/asynchronni
zapis, ale garantovane poradi zapisu, resp. minimalni interval mezi
operacemi patricimi konkretni transakci.

Matus Uhlar:
: Mozem vsak plne suhlasit ze celkova bezpecnost zapisu dat silne zavisi na FS
: a sposobe pracovania s nim. imho sa da vytvorit FS kde je synchronny zapis
: dat rovnako alebo menej bezpecny nez asynchronny.

	Samozrejme. Ale ja tvrdim neco jineho: Da se navrhnout asynchronni
zapis metadat tak, ze je stejne bezpecny jako synchronni (pochopitelne
pouzivaji-li oba asynchronni zapis vlastnich dat).

Martin Mares:
:    Zakladni idea: Zadna data az na superblok nemaji pevnou posici na disku,
: na vsechno tedy existuje nejaky pointer. Pokud prepisuji nejaky blok, nejprve
: vyrobim jeho novou verzi na jinem miste a pak teprve presmeruji pointer. Takto
: organizovane zapisy nikdy nedaji nekonzistentni data jinde nez v informacich
: o volnych blocich, jenze ty je mozno ze zbytku pri fsck trivialne odvodit.
: 
	Ano. Tohle lze jednoduse implementovat napriklad pokud kernel poskytuje
nejaky mechanismus zapisove bariery. Problem je ten, ze tohleto hodne
snizi vykon (temer nahodny prisup na disk). Lepsi by bylo mit moznost
urcovat poradi zapisu mezi jednotlivymi dvojicemi operaci.

	Zaver: Jeste porad me nikdo nepresvedcil, ze asynchronni
zapis metadat v ext2 nemuze byt stejne bezpecny nez synchronni napriklad
ve FFS.

-Yenya

--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\      Czech Linux Homepage:  http://www.fi.muni.cz/~kas/linux/        ///
///  die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);  \\\
//                            -- from linux/arch/sparc64/kernel/traps.c   \\