Názory k článku ExTiX: kompletní distro, které se vměstná do RAM
-
DD (neregistrovaný)
Mne se to nezda jako prilisna novinka, to nahrani se do RAM. Vzdyt to umi vselijake distribuce a nic na tom neni (v initrd vytvoreni ramdisku, zkopirovani rootfs, init). Treba v Debianu by melo stacit nainstalovat balik "live-boot-initramfs-tools" a pridat boot parametr "toram"... Nebo neco zasadniho prehlizim?
-
karel (neregistrovaný)
Zajimalo by me mereni rozdilu odezvy a prece se systeme pokud by byl provozovan v ram, hdd, ssd
mohlo by to byt docela zajimaveIkdyz mi to nasadilo brouka do hlavy, ajo dnes mame tolik ram ze nevime co s ni, tak proc kupovat male ssd kdyz muzu mit v nb terovi disk a system mit v ram, kvuli rychle praci, idealne pak mit zrcadlene nektere slosky na disku take v ram.
-
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.
-
talpa (neregistrovaný)
to jsem se zas nasmal, o distribuci nic nevim, ale kdyz jsem cetl o tom ze by autor rad vyucil LibreOffice Calc misto textovych editoru, docela me to rozesmalo. Netusite jak velky balik software Libre je a nic o jeho zavislostech. Textove editory se hold dotahuji lepe. Zkuste to napsat autorum at se zasmeji take.
-
nobody (neregistrovaný)
napr. v debian-live-xfce s velikosti iso 1.1GB, nemas zadne oklestene LXQt a pouze LibreOffice Writer, ale kompletni DE Xfce4 a kompletni LibreOffice a cele se to nahraje do RAM take... takze nemlat tolik hlavou do zdi, treba nebudes psat takove nesrozumitelne kraviny ty jeden netusici zavislaku :-D
-
Chcel by som sa opytat ci neexistuje distro (popripade strucny navod ako si ho vyrobit) ktore by dokazalo toto:
1. nabootovat z USB
2. nasledne na tomto USB dovolit zapisovanie napr aktualizovanie softwareu (apt-get upgrade) a pod.
3. najlepsie by bolo keby sa zapis na USB udial az po nejakom commite, v pripade ze sa update nepodari tak sa proste restartne PC a Linux je v rovnakom stave ako pred updateom
4. vsetky docasne data by si live system vytvaral na disku (aby sa zbytocne neskracovala zivotnost USB zapismi)Dakujem
-
nobody (neregistrovaný)
1. v podstate kazde distro
2. debian, ubuntu
3. ext4 ma volbu mount commit=kolik_vterin
4. docasne jako /tmp /var/tmp ? takove dir si namountis pres tmpfs(do ram), nebo na ten disk...ad 2.:
ubuntu:
vytvoris primo z nabehleho *buntu pomoci "Tvurce spousteciho disku", zaskrnes data ukladat a vyberes jako velikost (max 4GB) tomu chces pridelit, pri startu pak volis polozku persistent (btw: soubor pro zmen je image s nazvem "casper-rw" a parametr pro jeho vyuziti je "persistent")
info napr.: https://wiki.ubuntu.com/LiveUsbPendrivePersistentdebian:
iso nahrajes na usb pomoci dd, do polozky syslinux pridas parametr "persistence" a sobor pro zmeny vytvoris rucne nazev souboru "live-rw" s nazvem oddilu (volume label) "persistence"
viz: http://live.debian.net/manual/current/html/live-manual/customizing-run-time-behaviours.en.html#557odvozeniny debianu a ubuntu na tom budou podobne...
nebo Slax, kde nemas apt-get, ale jednotlive moduly v squashfs ktere ulozis na usb do slax/modules, zmeny v image nebo adresari (umi i linux atributy na fat32), rootcopy dir na usb z ktereho kopiruje pri startu do uloziste zmen...
http://www.slax.org/en/documentation.phpnebo obecne rucne...
- system je/budes mit v squashfs readonly image (kterej odnekus primountnes do initrams, nebo pred tim zkopirujes do ram)
- pripravis si image s extX filesystem, nebo partisnu(nebo adresar) pro ukladani zmen
- pomoci overlayfs (unionfs, aufs) to na sebe navrstvis
- pokud nechces ukladat zmeny prubezne, muzes je nastavene do ram a jenou za cas(cronem), nebo rucne(pustenim prikazu, poklepanim na ikonu) provedes sync na usb, nebo zabaleni do squashfs souboru na usb(a pri startu to rozbalovat do ram)... -
Dakujem pekne za odpoved. 4 bodom som mal na mysli subory ktore si Linux vytvara pocas behu. Neviem ci sa /proc da povazovat za nieco taketo, asi skor nie pretoze to nieje fyzicky na disku pokial viem, no napriklad nejake subory ktore vznikaju v /tmp pri pozerani flash videii a pod. Bod 1. bootovanie z USB som samozrejme skusal, pokial viem tak sa to lisi od distra k distru (aj ked tusim som na rootovi videl v diskusii nejaky "univerzalny" nastroj) na niektore som pouzil unetbootin na ine dd a pod. Pravdupovediac nikdy som neskusal dat apt-get upgrade na systeme beziacom z USB, pripadalo mi to ako hlupost kedze by to mal byt vpodstate klon live CD a tam clovek bezne taketo veci predsa nerobi. Az neskor som rozmyslal ze by nebolo odveci si na taketo live USB nainstalovat aj veci kotre napr na Live CD ubuntu niesu (nejakde drivery a pod, vpodstate to asi nema daleko od vlastneho distra) a tym padom mat USB ktore je mozne drzat aktualne (ak by clovek nechcel bootovat live system na fyzickom zeleze len koli tomu aby urobil update tak raz za cas by sa USB dalo nabootovat do virtualboxu a odtial spustit apt-get update) Ked spravne chapem tak bod 2. je vlastne nainstalovanie systemu na USB, ci nieco ine? Veci ktore si popisal su na mna trochu advanced, ako zhruba chapem o com je rec ale nikdy som nic take nerobil. Nechcelo by sa ti o tom napisat nejaky blog :)? Hlasim sa ako tester, pripadne ak by si mi dal na seba kontakt tak by som to skusil ale s tym ze asi by som ta na zaciatok otravoval hlupymi otazkami ;) moj email: wakatana(at)gmail(dot)com Dakujem
