Fcache - výrazné zrychlení bootu (diskuse)

[fakenickname]

To zní zajímavě, věděl by někdo víc? V angličtině to nepřelouskám.. Kdyby někdo věděl jak to funguje,jestli je to použitelné a kdy se nám to objeví v repositářích tak ať honem píše blogpost :)

[Martin]

Může mi někdo laicky vysvětlit na jakém principu ten patch funguje? Nějak mi nejde do hlavy, proč se na to třeba nepřišlo už dřív a v čem by mohla spočívat ta finta.

[xxx]

Projel jsem ten anglický text a chápu to zhruba takto. 1. Vytvoří se partišna pro tu cache. 2. nastaví se tak, aby se při startu přimountovala v "zaznamenávacím" módu. 3. Resetuje se stroj a při spuštění se data, který jsou různě na disku zkopírují (v pořadí v jakém se načítají) na tu cache partišnu. 4. změníš parametr aby se partišna při startu mountovala ve "čtecím" módu. Data jsou na ní uspořádaná v pořadí v jakém se čtou a tudíž disk tolik neseekuje a boot je rychlejší.

Tak to je můj rychlovýcuc.

[Josef Kufner]

Po přečtení několika prvních odstavců jsem došel k tomu, že to funguje tak nějak takto:

Při prvním bootu se nahrávají načítaná data z disku na zvláštní kešovací partišnu, takže jsou tam pak uložena hezky postupně, tak jak jsou potřeba.

Při dalším bootu se místo na původní filesystém přistupuje na tuhle kěsovací partišnu, takže požadovaná data jsou ve správném pořadí a disk nemusí hýbat hlaviučkama víc, než je třeba a readahead cache se krásně uplatní, takže ve výsledku je načítání o kus rychlejší.

Ale i tak si myslím, že pokud je potřeba rychle bootovat, tak je daleko lepší nějaký druh suspendu (swsusp2 např.).

[Ctirad Feřtr]

Eh, to jsou obézličky Spíš bych doporučil autorům ryze desktopových dister zamyslet se na tím, jestli nenahradit stávající init s rc skripty něčím diametrálně jiným, co nebude během bootu procházet a parsovat desítky textových souborů a interpretovat prográmky v nich napsané, což je právě to, co nejvíc zdržuje. Samotný linux bootuje zatraceně rychle.

Ostatně kde je psáno, že desktopový systém založený na linuxu (a navíc s jedním nebo maximálně pár uživateli), musí být nutně koncipovaný stejně, jako velký unixový server, že ano?

[Michal Kubeček]

Zajímavá idea. Vy tedy tvrdíte, že overhead na interpretaci startovacích skriptů systému je tím nejvíce zdržujícím prvkem. A že pokud by start systému byl realizován nějakými programy psanými v kompilovaném jazyce, zrychlení by bylo tak výrazné, že by ospravedlnilo výrazné snížení flexibility takového řešení. K tomuto závěru jste došel na základě nějaké solidní analýzy problému a následných experimentů, nebo jde jen o obvyklé plácnutí naslepo?

[Filip Hesse]

Ono něco odlišného od rc skriptů a init už existuje, jenom si nevzpomenu na název. Jestli tomu dobře rozumím, jde o praralelní spouštění služeb. Proč by každá služba měla čekat, až předchozí odpoví "vše v pořádku, běžím"?

Nějak podobně nabíhají Win. Microsoft si s nabíháním dal práci. U Linuxu zatím nebyla potřeba to moc zkoumat, protože když 1x za rok vypneš server, aby jsi vyluxoval prach, je ti jedno, jestli nabíhá dvě nebo pět minut.

[Jiří (BoodOk) Kadeřávek]

Zrejme mluvite o runit.
Paralelni start sluzeb je IMO planovan do dalsi verze Ubuntu.

[Michal Kubeček]

To je ale něco úplně jiného, než o čem tu byla řeč. Paralelní spouštění můžete realizovat i u shellových skriptů. Tady se prohlašovalo za naprostou samozřejmost, že největší brzdou je skutečnost, že se jedná o shellové skripty. Proto jsem vystoupil proti tomu, aby dotyčný něco podobného prohlašoval za zřejmé, aniž by si nejdřív ověřil, zda to tak opravdu je.

[MiG]

runit neni jen paralelni bootovani, to je vlastne vedlejsi efekt - hlavni vyhodou je nepouzivani pid souboru, takze kdyz neco spadne, tak to je proste spadle a ne ze "is running (pid file exists)"

viz clanek Od initu k runitu

[Ctirad Feřtr]

Zajímavá idea. Vy tedy tvrdíte, že overhead na interpretaci startovacích skriptů systému je tím nejvíce zdržujícím prvkem.

Ano, to tvrdím. Ostatně i průměrně bystrý uživatel si při startování systému všimne, že vlastní inicializace jádra trvá pár vteřin, pak se řádově minutu chroustají startovací skripty a po startu X nabíhá desktop opět jenom pár vteřin.

A že pokud by start systému byl realizován nějakými programy psanými v kompilovaném jazyce, zrychlení by bylo tak výrazné, že by ospravedlnilo výrazné snížení flexibility takového řešení.

Všechno co říkám je, že by bylo dobré se zamyslet, jestli je stávající řešení vhodné na desktopové použití a jestli by se nevyplatilo vymyslet něco mnohem efektivnějšího. Navíc tím vůbec nemusí utrpět flexibilita. Možná dokonce naopak.

K tomuto závěru jste došel na základě nějaké solidní analýzy problému a následných experimentů, nebo jde jen o obvyklé plácnutí naslepo?

Ano, došel. Pro jednu firmu jsem vyvinul embedded systém založený na linuxu, který po inicializaci jádra dělá naprosté mimum ve skriptech (v podstatě jenom udev a nastavení pár proměnných) a hned spouští vlastní "multimediální" aplikaci. Doba bootu cca 10s.

Nějaké další jízlivé poznámky?

[Michal Kubeček]

Ostatně i průměrně bystrý uživatel si při startování systému všimne, že vlastní inicializace jádra trvá pár vteřin, pak se řádově minutu chroustají startovací skripty a po startu X nabíhá desktop opět jenom pár vteřin.

Pokud je ovšem ten uživatel opravdu bystrý průměrně a nikoli podprůměrně, všimne si také toho, že ty shellové skripty neběží jen tak naprázdno, ale spouštějí určité programy. A že přepracováním těch skriptů na něco efektivnějšího můžete ušetřit nanejvýš čas, který trvá vlastní interpretace skriptu, ne to, jak dlouho běží programy z těch skiptů spouštěné.

Navíc tím vůbec nemusí utrpět flexibilita.

To dost těžko. Právě možnost upravit si skript podle potřeby je IMHO hlavní výhodou řešení založeného na shellových skriptech.

Ano, došel. Pro jednu firmu jsem vyvinul embedded systém založený na linuxu, který po inicializaci jádra dělá naprosté mimum ve skriptech (v podstatě jenom udev a nastavení pár proměnných) a hned spouští vlastní "multimediální" aplikaci. Doba bootu cca 10s.

To je ovšem něco úplně jiného, než na co jsem se ptal. Vy jste použili klasický model startovacích skriptů, pouze jste je pročistili a seřadili je (pro vás) vhodnějším způsobem. To by ovšem svědčilo spíš o tom, že koncepce není špatná a problém je spíš v tom, jak jsou ty skripty napsány. V minulém příspěvku jste ovšem (naprosto suverénně) mluvil o výrazném zrychlení bootu tím, že by se místo shellových skriptů použilo něco efektivnějšího, předpokládám, že kompilované programy. Proto mne zajímalo, zda pro své tvrzení máte nějaký podklad - třeba to, že byste na reálném desktopovém systému změřil celkový čas procesoru, který během bootu systému spotřebují jednotlivé shelly. Vzhledem k tomu, že na mých systémech po celodenní práci má nejvytíženější shell na svém kontě nanejvýš tak dvě sekundy času procesoru, odhadoval bych, že to nebude stát za řeč. Nebo jestli jste opravdu nezkusil použít místo shellových skriptů kompilovaný program. Pokud to neuděláte, musím vaše radikální tvrzení opět považovat jen za takové plácnutí do vody.

[Ctirad Feřtr]

Ale já jsem sakra nikde netvrdil, že skripty jsou tou jedinou brzdou. Mluvil jsem o celém init procesu a o tom, že by bylo dobré se zamyslet nad tím, že desktop není server a jestli by nebylo vhodné celý ten proces, převzatý se serveů, překopat. To, že chci nahrazovat nějaké skripty kompilovanými programy mi podsouváte pořád akorát vy.

[Michal Kubeček]

Promiňte, ale pokud napíšete

co nebude během bootu procházet a parsovat desítky textových souborů a interpretovat prográmky v nich napsané, což je právě to, co nejvíc zdržuje.

těžko to mohu chápat nějak jinak.

Co se týká reorganizace skriptů samotných, jsem dost skeptický k tomu, do jaké míry je jejich redukce obecně možná. Zkušený uživatel si může vyházet nepotřebné služby a inicializace toho, o čem ví, že to používat nebude. Ale desktopové distribuce (teď mám na mysli distribuce typu Red Hat, Mandriva, SuSE) musejí ve svém defaultním nastavení počítat spíše s uživatelem, který problematice moc nerozumí. Proto se spouštějí záležitosti typu mdnsd, které sice většina uživatelů nepotřebuje, ale někdo ano. Proto se všude spouští CUPS bez ohledu na to, zda uživatel potřebuje tisknout nebo ne. A tak by se dalo pokračovat. Tyhle mainstreamové distribuce bohužel nemohou sázet na to, že stačí spustit nezbytné minimum a uživatel si doplní, co bude potřebovat. Mne třeba také zrovna moc nebaví po instalaci nové verze systému pokaždé vyhazovat hlouposti typu SuSEwatcher nebo SuSEplugger (dodnes si nepamatuji, který je který), zvlášť když jich s každou verzí přibývá, ale beru to jako nutnou daň za to, že je systém použitelný i pro uživatele, kteří toho o jeho fungování moc nevědí.

[Ctirad Feřtr]

Promiňte, ale pokud napíšete

co nebude během bootu procházet a parsovat desítky textových souborů a interpretovat prográmky v nich napsané, což je právě to, co nejvíc zdržuje.

těžko to mohu chápat nějak jinak.

Tak to cháptete špatně nebo jsem to možná nenapsal dost jasně. Jde mi samozřejmě o celý proces initu včetně těch skriptů a prográmků, které ty skripty spouští. Samotné nahrazení shellových skriptů něčím kompilovaným je samozřejmě blbost. Ale dalo by se začít třeba jenom tím, že by se mnohé úkony služby mohly provádět/spouštět na pozadí až po stratu X, respektive po naskočení loginu.

[Michal Kubeček]

Ale dalo by se začít třeba jenom tím, že by se mnohé úkony služby mohly provádět/spouštět na pozadí až po stratu X, respektive po naskočení loginu.

Nejen že by mohly, ono se to tak už mnohde dělá.

[Ctirad Feřtr]

A kde třeba? Docela rád bych se inspiroval.

[Michal Kubeček]

Třeba SuSE 10.1:

mike:/etc/init.d/rc5.d> ls -1 S*
...
S08xdm
S09atd
S09nscd
S09sendmail
S09stunnel
S10cron
S10timesync
S11cupsrenice

Samozřejmě by se to dalo vylepšit, ale takhle je to bez jakýchkoli úprav, jen jsem některé služby přidal a některé odebral.

[David Jež]

Přesně tak, start může být v závislosti na natahovaných věcech různě pomalý. A může za to více věcí -- také záleží na tom, jak jsou ty skripty dělané. Obecně rc. skriptové distribuce (jako je třeba Slackware) mi startují rychleji než init.d distra -- nebude to možná vina shellu jako takového, ale start každé služby je realizován na init.d systému jako jednotlivé soubory, nutně tedy provádí více operací. Navíc nejde jen o spouštění služeb, ale v init.d skriptu se často natahuje konfigurace, v každém skriptu zvlášť, v podstatě tytéž věci dokola. Sám používám svc od djb, takže mohu srovnávat binárky a skripta, ne tedy, že by někdy byl ten rozdíl obrovský, ale problém je ještě někde jinde:

Typický uživatel desktopu hlavně chce, aby mu co nejrychleji naběhlo nějaké desktopové prostředí a co je pod ním ho nezajímá. Ono udělat systém, kde by se co nejrychleji jak je to možné natáhnul udev, hotplug, moduly a nějaké ty věci kolem, nastavil loopback a nastartovaly Xka a pustil *dm by stačilo. Než se potom uživatel stihne přihlásit a vůbec mu nastartuje KDE/GNOME/... tak mohou startovat další věci, klidně paralelně -- většině služeb je fuk, v jakém pořadí nastartují. Akorát je problém právě s paralelním během -- představa, že by zaráz běžel ldconfig, fc-cache, natahovaly se programy a do toho se snažil číst desktop je děsivá. Bez priorit a nějakého rozumného přístupu k disku by takový systém byl kontraproduktivní.

O flexibilitě by se dalo polemizovat, já si zase naopak myslím, že nějaký binární systém s modulama a inteligentní konfigurací, nastavenou databází a jednoduchým přístupovým API ke konfiguraci by naopak pro tzv. desktopové distribuce byl možná lepší než současná praxe každý pes jiná ves. Textové soubory jsou super věc a dobrá věc pro člověka, ale pro parsery je to noční můra. Nakonec to dopadá tak, že půlka věcí se generuje a nějak přepisuje automaticky a zbytek se snaží parsery nějak zpracovat. Přídávat a odebírat služby automaticky potom pro klikací systém není zrovna triviální a když se něco rozdrbe, tak stejně se v těch distribučních šílených skriptech o tisíci řádcích všichni samozřejmě vyznáme, že? Automatický systém by to aspoň řešil. My co chceme upravovat texťáky máme své distribuce. A klikači by měli aspoň své desktopové distribuce, kde si můžou všechno naklikat, a nemuseli bysme se za ně drbat v těch šílených skriptech, když se něco sesype... Asi tak.
-djz

[Ctirad Feřtr]

K tomu není co dodat. Přesně jste vystihl, co se mi honilo hlavou, když jsem psal ten původní příspěvek.

[peter_h]

Ja si skor myslim, ze samotne skripty sa vykonavaju velmi rychlo, ale seekovanie na ich nacitanie trva dlho, tiez kazdy skript nacitava nejake konfiguraky=dalsie seekovanie + sa caka na rozne zariadenia, ci uz su "up"+sa pri tom spustaju rozne pomocne programiky=dalsie seekovanie. Najvacsie zrychlenie ohladom seekovania by asi bolo dat vsetko potrebne pri starte na nejaku komprimovanu partition a ohladom cakania je asi jedine riesenie - sparalelnit co sa da.

[zde]

Nějaké další jízlivé poznámky?

Nic si z toho nedělejte, autor je pedagog a nemůže za to. :)

[Michal Kubeček]

Ne, autor má jen z různých diskusí své zkušenosti s tím, jak důvěryhodná a jak důkladně ověřená bývají tvrzení, která pan Feřtr prezentuje v diskusích coby zjevnou pravdu…

[Ctirad Feřtr]

To je ale od vás hodně velká a sprostá podpásovka. To, že se vám něco hehodí do krámu ještě neznamená, že je to nedůvěryhodné tvrzení. Ostatně pokud vím, tak veškeré naše konflikty spočívaly v tom, že nenávidíte Qt/KDE, Gentoo a ještě nějaké další věci.

A ostatně vaše podivná konfrontační rétorika je jasně vidět z výše uvedené diskuse, kdy mě obvinujete z toho, že plácám blbosti, jenom proto, že jsem něco nevyzkoušel, přestože vy sám jste to samozřejmě taky nevyzkoušel, ale svoje ničím nepodložené tvrzení přesto považujete za jedinou důvěryhodnou pravdu.

[Michal Kubeček]

No, řekl bych, že kdybych tak strašně nenáviděl Qt/KDE, těžko bych KDE už přes čtyři roky používal jako své desktopové prostředí. Pokud jste myslel Gnome, tam mám určité výhrady k tomu, kam se poslední dobou ubírá vývoj jeho GUI a na jakých myšlenkách je založen; ale že bych ho nenáviděl? To určitě ne. Co se týká Gentoo, to, že ho nenávidím, je jen a jen vaše fabulace. Tehdy šlo čistě o to, že jsem upozorňoval, že Gentoo není lék na všechny neduhy světa, a konkrétně jsem ukazoval na nevýhody jeho kontinuálního vývojového modelu pro nasazení v enterprise prostředí, kde je prioritou stabilita. Nikdy, a to zdůrazňuji, jsem nenapsal, že je Gentoo špatné jako takové. Ostatně, tyhle přestřelky jsem teď na mysli neměl, šlo spíše o věcné chyby ve vašich příspěvcích, které byly prezentovány bez jakéhokoli dodatku typu IMHO nebo AFAIK.

Co se zkoušení týká, na startovacích skriptech jsem overhead shellu skutečně nezkoušel. Ale pokud shell, se kterým celý den intenzivně pracuji, nasbírá nanejvýš nějaké dvě sekundy času procesoru, považuji to za dost směrodatné na to, aby to vaše tvrzení přinejmenším zpochybnilo.

[Ctirad Feřtr]

Pokud vidíte věcné chyby, tak na ně prosím reaguje opět věcně a se zdůvodněním. Já pak rád uznám, že jsem se zmýlil, ostatně jako už v minulosti několikrát.

Opravdu mě ale strašně vytáčí (a netvrdím, že to děláte vždycky zrovny vy), když někdo něco překroutí a reaguje na něco, co tam není a jako dodatek hned přidá pár osobních útoků. Mě v té chvíli samozřejmě nezbývá, než mu oplácet stejnou a nijak mě to netěší. Dusno v diskusích a flamewary opravdu nevyhledávám.

[Jiří (BoodOk) Kadeřávek]

Clovece vy napisete hovadinu a kdyz vam nekdo vytkne, ze varite z vody, a to jste skutecne udelal, tak ho obvinite z konfrontace. Nechcete se nad sebou zamyslet? Proste kdyz na to nemam, tak tady svoje smyslenky neprezentuji jako fakta a nemusim se potom stavat tercem posmechu. Vice studujte, mene tlachejte.

[Jiří (BoodOk) Kadeřávek]

Ano nejlepsi by bylo startup skripty a jejich konfigurace zahrnout primo do jadra. To by byl teprve ficak

[genius2000.log]

Já jsem se svým Arch Linuxem spokojen. Boot do KDM trvá 20 sekund. Je to tím, že používám upravené skripty z FreeBSD

[Mikos]

Jo, Arch Linux bootuje velmi rychle, jeho BSD-like init skripty jsou výborně navržené, velmi jednoduché a přehledné. A strašně moc se mi líbí jednoduchost a přehlednost rc.conf. Sám většinu init skriptů spouštím paralelně na pozadí (stačí v rc.conf před příslušný daemon přidat znak @), ale boot až do KDM mi trvá stejně o něco déle (asi 31 sekund). S fcache se to dá aspoň o 10 sekund ještě stáhnout.

[Martin]

Díky moc za vysvětlení. Zní to celkem použitelně ;o)

[Libor Klepac]

to je asi pro lidi, co moc neupgraduji ... predpokladam, ze kdyz vytvorim cache, pak upgradnu program a pak rebootnu, tak se mi z cache nacte stara verze

[Jiří (BoodOk) Kadeřávek]

To ne, fcache si zjisti aktualnost kesovane verze souboru a pripadne si jej zaktualizuje. Takze muzete upgradovat jak chcete.

[Libor Klepac]

je to chytrejsi nez ja ... bojim se toho ;)