a metaadat változtatások írása a logba történik, melyből egy darab van per filesystem. create/delete, meg ehhez hasonlók műveletekről beszélünk, ezeket írja sorfolytonosan oda.
melynek random blokkjait egy random tartalmú korábbi verzióval "felülírtad".
ezek után a legközelebbi alkalommal a "hülyeségeket" amik a felülírt blokkokba kerültek (create/delete meg hasonló műveletek) a filesystem végre is hajtotta. te meg meglepődtél.
ha a fenti raid0-ás műveletet egy oracle adatbázissal játszod el, akkor ő simán észreveszi a minden adatbázis blokkban levő checksum alapján. és közli veled, hogy akkor most vegyed elő a backupodat, mert megsérült a diszken az adat, és gyakorlatilag kuka az adatbázis.
a probléma lényegi része, hogy minden valamirevaló filesystem elvárja, hogy ha az 1-es blokk kiírását visszaigazolta a diszk, majd ezután a kezdeményezi a 2-es blokk írását, akkor semmilyen áramszünet esetén nem elfogadható, hogy a 2-es blokk kikerült a diszkre, de az 1-es meg nem. ezen feltétel biztosítása nélkül nem lehet értelmes journaling fs-t írni. az egy szimpla mázlifaktor pl., hogy az ext3 cache flush algoritmusa mellett ez a szituáció ritkán okoz hasraesést. de ott sincs kivédve, csak ritkább a szívás.