Názor k článku ExTiX: kompletní distro, které se vměstná do RAM od Vít Šesták - Pád v případě klasického R/W setupu: Pokud mám...

Pád v případě klasického R/W setupu: Pokud mám vhodně nastavený FS (např. ext4 s data=ordered a žurnálem pro metadata) a dobře napsané aplikace, pak by se to stát nemělo. Příklad: Aplikace chce atomicky upravit soubor x.dat. Nechce dělat žádné žurnálování uvnitř souboru (což by ale byl dost podobný případ, jen komplikovanější):

1. Aplikace vytvoří soubor x.dat.tmp a zapíše do něj nová data.
2. Aplikace zavolá fsync na x.dat.tmp.
3. mv x.dat.tmp x.dat

S vhodným FS a vhodnými parametry mám zaručeno, že v x.dat bude vždy buď původní obsah, nebo nový obsah, ale nic mezi tím. V případě syncu se to může pokazit na několika místech:

1. Čtení souboru není atomické a nevím, jak to jednoduše udělat. Pokud se mi při syncu bude měnit obsah souboru pod rukama, můžu pak dostat nějakou dost nekonzistentní verzi, která neodpovídá ani jednomu okamžiku. (Toto se netýká zmíněného atomického nahrazení, ale týkalo by se to in-place změn v databázi.)
2. Čtení celého FS není atomické. (Resp. není snadné to vyřešit atomicky.) Pokud přesouvám soubor, můžu ho při čtení celého FS najít na obou místech. Pokud budu syncovat sqlite databázi, můžu dostat jinou verzi žurnálu a jinou verzi samotné DB, protože to jsou AFAIK v oddělených souborech. A dalo by se pokračovat.
3. Zápis souboru na výsledné místo nemusí být atomický. Může se mi pak stát, že zapíšu půlku souboru a pak mi to kiksne.
4. Zápis změn není atomický a neprobíhá v původním pořadí. Například po přesunutí souboru se mi může snadno stát, že nejdřív syncnu jeho smazání z původního umístění a potom teprve syncnu jeho zápis na nové umístění. Co se stane, když to kiksne během synchronizace, nemusím snad dodávat. A pominu fakt, že tady jsem zrovna moc I/O neušetřil (spíš naopak).

Neříkám, že to nejsou řešitelné problémy. Ale za jakou cenu? Atomické čtení celého FS by se ještě dalo nějak udělat (např. COW snapshoty v LVM na nějakém blokovém device v RAM). Atomický zápis teoreticky taky – to zkopírování jednoho velkého souboru, které zmiňuješ, by řešilo atomický zápis kompletně, pokud se provede vhodně. Ale udělat atomický zápis tak, aby to neznamenalo zapsat velký objem dat, není sranda. Pak můžeš snadno skončit s řešením, které pro svou reřii bude potřebovat více I/O, než kolik ho ušetří.

Pro mě tu nejsou až tak problém ztracená data, která se nestihla syncnout – to se může stát v různých podobách vždy. Ani není problém, že se mohu přijít o data – pokud mi odejde karta, taky přijdu o data, takže tak jako tak bych měl zálohovat. Problém je trochu v tom, že se mi mohou poškodit data, ale já na to nemusím hned přijít. Uvidím jen nějaké záhadné chování za nějaký čas. Nevím, že mám obnovit ze zálohy.

„neustale nekde ctu jak nekomu odesla v rpi karta (pri vyuzivani rw instalu)“ – a kolik z nich píše, jak dlouho tu kartu používali? U mého staršího PC odešla základní deska. Jak nespolehllivá část počítače to je… (Že odešla po cca 7 letech používání, to je druhá věc.)