Vlákno názorů k článku ExTiX: kompletní distro, které se vměstná do RAM od Sinuhet - Běh OS z RAM má spoustu výhod. Potřebné...
-
Sinuhet (neregistrovaný)
Běh OS z RAM má spoustu výhod. Potřebné programy se často dají osekat tak, že se do RAM vejdou, a spuštěné aplikace zase tak, aby se vešly do toho zbytku :)
RAM se za běhu neopotřebovává. U systémů, které běží trvale, se to hodí. Třeba u RaspberryPI, kde prostě jednou denně syncnete ramdisk a SD kartu.Ale paměť dělá chyby, nebudu si dělat iluze, že zrovna u RPi to nebude problém. Zatím mi všechno funguje.
A u workstation s 32GB RAM mi za tu rychlost těch 8GB na systém vadit nebude.
-
Než dělat takovéto krkolomné věci s ramdiskem se všemi riziky synchronizace (race conditions a případné problémy v případě výpadku proudu kvůli změně pořadí a případné neatomicitě updatu souboru), to už bude IMHO lepší si nastavit k nějaké ext4 partition dlouhý commit. Mělo by to udělat plus mínus to samé, ale lépe si to poradí s případným nedostatkem RAM a zachovává to jistá očekávání. Pokud vadí fsync u některé aplikace, dá se použít nástroj eatmydata.
Navíc u takového řešení při troše neopatrnosti hrozí znovupoužití random seedu pro /dev/urandom. To je mimochodem potenciální problém i u všech live distribucí.
Samozřejmě, tento způsob práce se moc nehodí pro práci s důležitými daty. Pak je taky otázka, jestli jednou za několik let pár stovek za novou microSD kartu je opravdu tak velká nákladová položka, že toto má smysl řešit.
-
nobody (neregistrovaný)
na tom neni nic krkolomneho, rozdelit system na readonly cast kterou hodis do squashfs kterej pri startu nactes do ram a pres overlayfs tomu pridas readwrite vrstvu na karte je normalni reseni pro specificke situace...
misto 1/parLet menit microSD kartu by se ti mohlo totiz stat, ze nekolikrat/rok budes mit kartu v haji a nefunkcni system, nez vrazis zalohu na novou kartu za kterou tu vadnou vymenis...
-
Já říkám, že:
1. Udělat tu R/W vrstvu dobře je těžké, pokud uvážíme i náhodné vypnutí/pád systému během synchronizace. Může to změnit pořadí zápisů, může to zapsat půlku nové verze souboru a může to dělat snad i horší věci než data=writeback u ext4. Pokud je toto OK, tak nejspíš nejde o moc cenná data nebo jsou dobře zálohovaná jinde.
2. Je snadné při troše nepozornosti udělat reuse pro /dev/urandom. Možná to vadit až tak nebude, ale možná taky vzniknou RSA klíče se stejnými prvočísly[1] nebo ukradené Bitcoinové peněženky[2]. Jediné, co je jisté, že s takovouto chybou může systém být jinak plně funkční a nepoznáte to na něm. BTW, nedávno se mi díky chybě podobného charakteru podařilo několikrát z /dev/random získat totožných 128 bitů[3].
3. Máme tu řešení, které může být lepší – dlouhý commit a případně eatmydata.
Co se týče té karty, tak to záleží. V některých specifických vytíženích určitě ano. Já na Raspberry Pi provozoval ne úplně novou kartu bez podobných triků nějaký ten rok, než odešla. Navíc byla jen 4GiB, takže tu byla větší šance, že se budou přepisovat stejná místa. A ještě jsem na ní někdy swapoval…
Tvrdím, že i pokud mám flash úložiště (a to i pokud to není kvalitní SSD, ale „blbá“ SD karta), musí to být opravdu hodně specifická situace, aby mi podobné řešení přineslo tak velkou výhodu, že bych měl chuť překonat zmíněné nevýhody.
[1] https://factorable.net/weakkeys12.extended.pdf
[2] https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/
[3] https://twitter.com/v6ak/status/637712895325917184 -
nobody (neregistrovaný)
kdyz uvazujes vypnuti/pad behem sync, uvezujes take pad behem zapisu pri klasicke rw instalaci? prakticky v te nebezpecnosti za takove situace totiz nebude rozdil a muzes klidne nejdriv zabalit cele zmeny v ram do squashfs v ram a az ten pak zkopirovat jako 1velkej naraz soubor...
ohledne odchazeni karet vychazim z toho, ze neustale nekde ctu jak nekomu odesla v rpi karta (pri vyuzivani rw instalu), samozrejme zalezi na pouzivani, na noatime nastaveni atd, taky sem pouzival rok x86 desktop z microSD rw instalu vetne obcasneho swap, ale mel to odladene/zalohovane, karta ani neodesla, nahradil ji hdd...
-
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.datS 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.)
-
U ext4 nezaručuje data=ordered(*) v případě, že je povoleno delalloc(*), vůbec nic. Funguje to pouze u souborů, které se přepisují a nezvětšují. Odložená alokace (a tedy fyzický zápis dat) totiž nerespektuje commit=5(*) a dochází k ní (v případě že mezi tím neproběhne fsync) klidně až za neuvěřitelných 30-150 sekund! Delalloc ale není potřeba vypínat, negativní efekt popisovaného případu vyruší volba auto_da_alloc(*). (*) = výchozí volba
Je otázka, zda je to problém "dobře napsané aplikace". Podle mě je to problém ext4. Nevím o žádném jiném souborovém systému, který by vykazoval stejné potenciální problémy. -
Díky za doplnění, byť to asi nebude mít vliv na pointu toho, co jsem psal.
Nicméně o fsync jsem se zmiňoval –. Může být diskutabilní, jestli dobře napsaná aplikace musí používat vhodně fsync, nebo jestli dobře navržený FS by se měl bez fsync do nějaké míry obejít (a do jaké míry). Neznám auto_da_alloc tak dobře, abych z rukávu vysypal, jestli ruší všechny potenciální negativní účinky delallocu, nebo ne. vím, že je v některých případech potřeba pro zajištění konzistence.
