Proc Linux potrebuje defragmentaci

5.9.2006 12:53 | Přečteno: 5860× | Linux a tak | | poslední úprava: 6.9.2006 19:34

Update: Vzhledem k tomu, ze podle komentaru nekteri evidentne nepochopili, co jsem se snazil rict (hlavne test), je dole jeste zjednodusena verze c.2.
Update c.2: Jeste jedna vec asi neni uplne jasna. Tohle neni jen o bootovani. Z disku se cte i pri spousteni aplikaci a nebo proste i pri normalnim pouzivani (proc asi treba "svn status" nebo "find / -name cokoliv" trvaji tak dlouho?).

Ach jaj, root.cz asi uz sel definitivne do kyticek. Po katastrofach jako komiks ted i prebira clanky, ktere i ve sve puvodni verzi byly v komentarich pekne zkritizovane. Linux nepotrebuje defragmentaci, protoze ma lepsi filesystem nez takova prehistoricka vec jako FAT, bla bla bla. Tolikrat opakovany nesmysl. No, kdyz jde prekladat takovehle clanky, urcite jde prekladat i reakce, se svolenim autora nebude problem, ja si to klidne povolim.

Pokud tedy Linux ma tak genialni souborove systemy, tak proc Windows startuji rychleji nez Linux a proc druhy start KDE je nekolikanasobne rychlejsi? Navic, pravda je takova, ze uz jen mluvit o defragmentaci je nesmysl. Defragmentace je o tom, ze jednotlive soubory budou ulozeny na disku vcelku a ne rozhazene po kouscich. Tzn. ze precteni jednoho souboru bude rychle a o cteni vice souboru se vubec nemluvi. Tak a ted, kdo z vas zna Linuxovou aplikaci, ktera pri startu cte jeden soubor? Ja ne. Soucasne aplikace jich ctou minimalne desitky, casto klidne i pres sto. Jenze o tom defragmentace prece vubec neni.

Technicka vsuvka: Moderni disky prectou klidne treba 50MB za sekundu v blokovem cteni, tzn. ze hlavicky najednou na prislusnou oblast disku a pak v kuse ctou. Jenze pred kazdym ctenim se musi nejdriv hlavicky na tu oblast nastavit a tahle pristupova doba je dneska tak prumerne zhruba kolem 10ms (a tuhle nebo lepsi hodnotu daji jen opravdu opravdu dobre disky). Aplikace matematiky prvniho stupne zakladni skoly pak pravi, ze za sekundu to jde tedy provest 100-krat. Hodne zjednodusene receno, plus minus autobus, za sekundu se precte maximalne 100 souboru (coz je nadhodnocene i podhodnocene cislo, jak se to vezme).

Takze, ted kvizova otazka: Jestli aplikace pri startu potrebuje sahnout na 100 souboru, povetsinou relativne malych, jak dlouho ji to bude trvat a k cemu ji bude defragmentovany disk?

Defragmentace souboru (jednotne cislo) je o nicem. Melo by se mluvit o defragmentaci souboru (mnozne cislo ... zatracene chybejici hacky a carky :) ). Jestli aplikace ctouci 100 souboru ma startovat rychle, musi system souvisejici soubory umistnit za sebou a cist je dohromady. Obrazky v puvodnim clanku, ktery radostne oznamuje, ze soubory se rozhazuji po celem disku, aby nebyly fragmentovane, jasne ukazuje, jaka je sance neceho takoveho. A Linux kernel, co vim, se stejne necim jako velke nacitani dohromady neobtezuje, takze je to vsechno jen na internich cache primo v harddisku, ktere jsou obvykle malinkate. Na blizici se SUSE Labs konferenci se chystam si o tomhle tematu pekne popovidat s kernelovymi kolegy a asi ze me nebudou mit radost.

A jiste, asi by slo, aby aplikace cetly souboru min, jenze, nejake cist prece musi a navic, proc potom je moznost si data na disku pekne rozdelit do adresaru a souboru, kdyz by se to stejne nemelo delat? (Samozrejme, i tak, stejne na to budeme muset v KDE zkusit udelat nejaky workaround, jako u spousty dalsich veci.)

A pokud nekdo chce jednoduchy test, staci postupovat asi takhle:

• Pokud je pouzita nejaka moderni distribuce jako treba posledni SUSE Linux, vypnou predcitani behem bootu z disku (chmod -x /sbin/preload pro SUSE)
• Reboot pocitace
• Zmerit dobu startu KDE, hodinky staci
• Logout z KDE
• Znovu zmerit dobu startu KDE
• Porovnat obe doby, druha bude nekolikanasobne mensi
• Jako root pustit hdparm -t <disk> (obvykle /dev/hda nebo /dev/sda) pro zjisteni prenosove rychlosti
• KDE pri startu pri startu urcite nepotrebuje nacist vic nez 100MB (ledaze by se spoustelo opravdu hodne aplikaci), takze staci 100 vydelit prislusnou rychlosti
• Kdyby mi nahodou nekdo tech 100MB neveril, tak po druhem startu staci pouzit udaj "cached" z "free", coz bude hodne priblizny odhad (a bude samozrejme dost mimo, pokud se pri bootu spousti i hodne jinych veci jako cups, squid atd.)
• Oba starty KDE by se mely lisit zhruba o tu dobu ziskanou vypoctem (2s pri 50MB/s a 100MB) a ne nekolikanasobne

Konec testu.

Verze c.2, s vysvetlivkami a bez zbytecne omacky:

Root.cz je na zacatku zminovany proto, protoze to tam vyslo. Jinak je mi to celkem fuk, nadaval bych, i kdyby to vyslo treba v Rudem Pravu.

Puvodni clanek tvrdi, ze neni zadny nastroj pro defragmentaci disku pro Linux, protoze neni treba. Tvrdi to na zaklade toho, ze Linux se snazi jednotlive soubory nefragmentovat, takze cteni jednotlivych souboru je v poradku. Zasadni problem je, ze totalne ignoruje fakt, ze prakticky kazda aplikace cte desitky nebo i stovky souboru. Algoritmy popsane v clanku sice minimalizuji vznik fragmentace jednotlivych souboru, ale nedelaji nic proti fragmentaci celeho souboroveho systemu, kdy jsou souvisejici veci rozhazene vsude mozne (clanek dokonce konstatuje, ze "Linux rozptyluje soubory po celém disku"). Z hlediska programu, ktere musi cist mnoho souboru, je tedy disk stejne fragmentovany, jen na jine urovni.

Tak, ted ten tajemny test:

• Pripadne vypnuti vsech preload mechanismu a reboot pocitace - bude cisty start, vsechno se bude muset cist z disku.
• Spusti se KDE poprve a meri se cas - tim se zmeri kompletni cas startu KDE, vcetne vlivu cteni z disku. Me vychazi asi tak 24s.
• Logout a opakovani mereni spusteni KDE - protoze vsechno nactene minule kernel nechal v pameti, nebude prakticky zadne cteni z disku, tj. druhy cas je start KDE bez vlivu cteni z disku. Me vychazi asi tak 7s.
• Uz zminovana zakladni matematika a trocha logiky pravi, ze cteni z disku je nejvyznamnejsi faktor pri startu KDE. Moje KDE tedy stravi cekanim na disk asi 70% doby, coz start prodluzuje na tri- az ctyrnasobek.
• Ignorovat uplne cteni z disku by nebylo spravne a navic by to nemelo zadnou spojitost z fragmentaci, ctenim z disku a tedy onim puvodnim clankem. Proto je treba jeste zapocitat, jak dlouho by to trvalo, kdyby se dosahlo maximalni rychlosti cteni z disku. Protoze KDE potrebuje mene nez 100MB dat a disk cte asi 50MB/s, veskere cteni, kdyby bylo linearni, by tedy melo trvat 2s. Tedy prvni start KDE by mel idealne trvat 9s oproti soucasnym 24s.
• Takze, suma sumarum, fakt, ze data na disku nejsou dobre organizovana a nejsou linearne ctena, prodluzuje start KDE z 9s na 24s, tj. na dvou- az trinasobek. Protoze nic neni idealni, rekneme, ze realne by slo data z disku precist za 5s misto 2s. Tj. start KDE by se z 24s zkratil na polovinu na 12s.

A v neposledni rade, jako dalsi potvrzeni toho, ze problem je realny, muze poslouzit (jak zmineno v jednom komentari) fcache, experimentalni patch, ktery napsal Jens Axboe a ktery pracuje tak, ze veskera potrebna data umistni linearne do specialni diskove oblasti, odkud se pri bootu ctou linearne a tedy znatelne rychleji.

Jeste porad neco, co jsem puvodne nenapsal dost srozumitelne?

       

Komentáře

[Martin Baleja]

Ten jednoduchy test ma jednu zavaznou chybu: nevim jak zmenit dobu startu KDE

[Luboš Luňák]

Ach jaj, a dokonce v obou pripadech :(. Zasadne musim delat preklepy, ktere meni vyznam.

[Filip Jirsák]

Podle ohlasů na root.cz ten článek asi nebude moc kvalitní. Ale polemozivat s článkem o defragmentaci disku tím, že článek začnu vydávat za článek o geniálním souborovém systému a následně zkritizuju pomalý start KDE, to je tedy opravdu originální. Navíc autor nemůže najít klávesy s nabodeníčky a pak musí v závorce složitě vysvětlovat, jaký je rozdíl mezi souboru a souboru…

[Filip Jirsák]

Varianta 2 je už o něco lepší Ale článek na Rootu je o defragmentaci, pod čímž se obecně má na mysli defragmentace jednotlivých souborů. A porovnává, jaký je rozdíl mezi fragmentací (nějakého) linuxového FS a FAT.

Vy zavádíte nový pojem, defragmentace souborového systému. Vysvětlujete proč je to důležité a že to má některé stejné důsledky, jako defragmentace (souborů). Tím spojováním jen přes slovo fragmentace ale činíte svůj text zbytečně nesrozumitelným. Protože (de)fragmentace souborů je z technologického i věcného hlediska úplně něco jiného, než ukládání některých vybraných souborů na disk tak, aby je bylo možné efektivně načítat "najednou".

Je to jako kdybyste napsal (trochu přeháním): "Včera vyšel v novinách článek o osobních autech. Osobní auto má pedály. Klavír má také pedály. Narozdíl od auta, které klaksonem vydává jen jeden tón, klavír umí zahrát tónů mnoho." A dál se věnoval klavírům.

[Luboš Luňák]

Jenze to je presne ono. Kazdy dneska rekne, ze linux prece zadny nastroj pro defragmentaci nepotrebuje, presne na zaklade článků (tady jsem si tedy tentokrat dovolil se obtezovat s nabodenicky :) ) jako je tenhle. Jenze evidentne nejaky takovy nastroj by se dost hodil (at se mu rika, jak se mu rika, hlavne kdyz s tim konecne nekdo neco udela) a tak tedy je ten puvodni clanek z praktickeho hlediska spatne. A to prirovnani s pedaly docela pokulhava, auta a klaviry maji k sobe znatelne dale nez usporadani dat na disku a ... er, usporadani dat na disku.

[Filip Jirsák]

Kazdy dneska rekne, ze linux prece zadny nastroj pro defragmentaci nepotrebuje, … Jenze evidentne nejaky takovy nastroj by se dost hodil (at se mu rika, jak se mu rika…

Defragmentace ve světe počítačů znamená umístění souborů tak, aby jejich obsah byl ve filsystému pokud možno souvislý a aby byl souvislý prostor volného místa. Nepřipadá mi šťastné nazývat nástrojem na defragmentaci ještě něco jiného, co se shodou okolností týká také disků a uspořádání dat.

A to prirovnani s pedaly docela pokulhava, auta a klaviry maji k sobe znatelne dale nez usporadani dat na disku a ... er, usporadani dat na disku.

Defragmentace neznamená uspořádání dat na disku, ale uspořádání částí souborů na filesystému. Defragmentovat jde i filesystém, který je vytvořen nad VLM, RAID, je roztažen nebo dokonce "rozproužkován" přes několik disků; defragmentovat jde i filesystém, který je mountován přes loop, uložen na CD nebo na magnetické pásce.

To o čem je blogspot je skutečně "uspořádání dat na disku", a to za účelem zrychlení bootování – je tedy nutné znát geometrii disku a její mapování a "rychlostní" charakteristiky disku. Mimochodem, ono urychlení by naopak nejspíš znamenalo fragmentaci souborů – bylo by potřeba umístit co nejvíce dat do malého počtu stop nad sebou na plotnách.

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

A jeste nam objasnete proc se o de/fragmentaci bavime. Abychom meli soubory na disku vcelku? Ne O to skutecne nejde. Jde o rychlost, cas, ne o soubory v celku. LL ma pravdu, zatimco vy si hrajete na slovicka. A navic, vase pojeti slova defragmentace je zvlastni. Defragmentace je proste defragmentace. A je jedno v jakem kontextu o ni hovorime, pokud diskuze o ni ma vest ke zrychleni prace pocitace.

[Filip Jirsák]

Fragment = část, úlomek. Defragmentace je tedy pospojování částí dohromady. Takže u defragmentace jde o to mít soubory v celku. Rychlost a čas jde získat třeba také nákupem rychlejšího harddisku – také tomu budete říkat defragmentace?

Mé vysvětlení defragmentace je stejné, jak vysvětluje defragmentaci např. Wikipedie. Princip, který vy nazýváte defragmentací, povede daleko spíš k fragmentaci jednotlivých souborů, protože to bude výhodnější pro načtení celého bloku souborů.

Na slovíčka si hraju schválně, protože mi nepřijde příliš šťastné jeden zavedený termín začít vykládat úplně jinak.

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

Kdyby se blogpost jmenoval 'Proc Linux potrebuje defragmentaci souboru', pak bych nereagoval. Tak ale nazvan nebyl a jsem presvedcen, ze LL tam to 'souboru' nedal zcela zamerne, zatimco vy se mu ho tam snazite podstrcit.

[Filip Jirsák]

Autor blogpostu polemizuje s článkem o defragmentaci souborů. Defragmentací se u počítačů zpravidla myslí defragmentace souborů. Takže pokud autor defragmentací myslí urychlení startu počítače, a nikde to neuvede, čtenáři bez křišťálové koule to asi těžko dojde.

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

On to nikde neuvedl? A o cem je, panenko skakava, jeho blogpost?

[Filip Jirsák]

Jediné vysvětlení toho, co podle autora spotu znamená defragmentace, vidím tady:

Defragmentace je o tom, ze jednotlive soubory budou ulozeny na disku vcelku a ne rozhazene po kouscich.

To mi jako definice defragmentace = rychlý start operačního systému nepřipadá. Ostatně kdyby autor začal spot

Tento příspěvek bude o urychlení čtení souborů při bootování Linuxu. Pracovně si to nazvu defragmentací.

tak tady tahle diskuze vůbec nevznikla, protože nebudu dobrovolně číst text, kde si autor vezme slovo s nějakým významem, a začne ho používat ve významu úplně jiném.

[Luboš Luňák]

tak tady tahle diskuze vůbec nevznikla, protože nebudu dobrovolně číst text, kde si autor vezme slovo s nějakým významem, a začne ho používat ve významu úplně jiném.

Citace z textu:

Navic, pravda je takova, ze uz jen mluvit o defragmentaci je nesmysl. Defragmentace je o tom, ze jednotlive soubory budou ulozeny na disku vcelku a ne rozhazene po kouscich. Tzn. ze precteni jednoho souboru bude rychle a o cteni vice souboru se vubec nemluvi. Tak a ted, kdo z vas zna Linuxovou aplikaci, ktera pri startu cte jeden soubor? Ja ne. Soucasne aplikace jich ctou minimalne desitky, casto klidne i pres sto. Jenze o tom defragmentace prece vubec neni.

Defragmentace souboru (jednotne cislo) je o nicem. Melo by se mluvit o defragmentaci souboru (mnozne cislo ... zatracene chybejici hacky a carky :) ).

Zbyvajici (velmi maly pocet) vyskyt slova defragmentace v textu se vztahuje k puvodnimu clanku. Treba by to nejdriv chtelo cist poradne?

[Luboš Luňák]

Ach ano, je tak vlastne jeden dalsi vyskyt, v nadpisu. "Proc Linux potrebuje defragmentaci". Kdyz se puvodni clanek jmenuje "Proc Linux nepotrebuje defragmentaci", kdo uhodne, proc to tak je?

[Filip Jirsák]

Já jsem si myslel, že je to tak proto, že příspěvek bude polemizovat s článkem na Rootu a bude o tom, proč Linux potřebuje defragmentaci. Ale on ve skutečnosti o defragmentaci vůbec není – což stále nepovažuji za geniální autorův tah, ale za nedomyšlenost.

Podle nadpisu a úvodu článku si totiž člověk udělá představu, o čem asi článek bude. A jak čte dál, snaží se další informace přidávat k tomu, co už se dozvěděl. Ale když autor začne tím, že bude psát o defragmentaci, a pak udělá odbočku k rychlosti bootování na celý článek, čtenář se v textu ztratí.

Už ani nemluvím o naivitě, s jakou si představujete práci počítače – updatem č. 2 jste jí předestřel v celé její kráse: je to naivní představa, že by soubory šly seřadit na disku za sebou tak, aby vždy nebo v nezanedbatelné většině případů byly soubory, které se používají po sobě, byly také po sobě na disku. Ono by pak vlastně ani nebyly potřeba harddisky, kde se může náhodně přistupovat k libovolné části, a stačila by datová páska, kde by bylo vše pěkně za sebou. Asi nemusím připomínat, že přechod z pásky na úložiště s náhodným přístupem byl považován za inovaci právě proto, že v drtivé většině případů není možné určit, v jakém pořadí se bude se soubory pracovat…

[Mikos]

je to naivní představa, že by soubory šly seřadit na disku za sebou tak, aby vždy nebo v nezanedbatelné většině případů byly soubory, které se používají po sobě, byly také po sobě na disku.

To není žádná naivní představa, ono to tak zařídit skutečně jde (i když samozřejmě ne na všechno, pouze na deterministické věci jako je boot systému a start desktopového prostředí, start některých programů, atp.). Viz fcache o které jsem se tu zmiňoval několikrát. Jestli vám nepřijde zrychlení bootu o několik desítek sekund jako důkaz, je to váš problém Kdyby to bylo řešeno nějak obecněji, dal by se podobný koncept využít i na jiné věci než jen zrychlení bootu a startu desktopového prostředí (třeba zrychlení startu některých velkých programů).

[Michal Kubeček]

S mnoha soubory pracuje několik různých aplikací a jen těžko lze garantovat, že je všechny budou číst ve stejném pořadí.

[Mikos]

To sice ano, ale jak je vidět na příkladu fcache, velmi výrazného zrychlení jde přesto dosáhnout.

[Michal Kubeček]

Výrazného zrychlení čeho? Jedné konkrétní akce, navíc akce, kterou jsem donedávna prováděl právě jednou denně (a to jsem ještě během ní dělal něco jiného) a teď, co jsem si zvykl na suspend to disk, ještě asi tak o řád méně často. Připojuji se k názoru Martina Mareše, že až bude zrychlení startu systému nebo KDE o pár sekund (pro mne za mne i o pár desítek sekund) tím nejužitečnějším, co se dá pro vylepšení Linuxu udělat, budeme si moci pískat. Do té doby bych byl raději, pokud by se odpovídající úsilí věnovalo něčemu přínosnějšího.

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

Treba plkani na ABC linuxu, co jest nejprinosnejsi. Jen doufam, ze to neskonci u JXP commanderu

[rastos]

Ja teda nechcem kecat do veci o ktorych nic neviem, ale ... ak cielom defragmentacie je dosiahnut, aby jednotlive bloky s obsahom suboru boli pri sebe, tak to moze byt nespravny ciel. Pretoze data neodtekaju z disku tak rychlo ako sa nacitaju. Precita sa kus dat do interneho bufferu a z neho sa posielaju dalej, ked sa odoslu, tak sa ma precitat dalsi kus dat, ale medzicasom sa hlavicky disku uz posunuly o kus dalej. Ak by boli data ulozene kontinualne tak by sa muselo pockat nieco vyse obratky nez sa hlavicky dostanu zasa nad ten spravny sektor. Vola sa to Interleaving MS Windows optimalizuju ulozenie suborov potrebnych pre boot vzhladom na taketo chovanie a ziskavaju tym na rychlosti. V linuxe su si vsetky subory na disku rovne a takato optimalizacia sa nerobi.

Druha vec je to, ze sa robi read-ahead (ci look-ahead). Teda ked uz sa cita sektor na nejake stope tak sa uz precita cela stopa. Ak sa teda dalsie subory potrebne pre start nachadzaju "blizko seba", tak je sanca, ze sa najdu v cache a nemusia sa hladat na disku.

Suma sumarum - nekecajme do toho ludom co to programuju a velmi pravdepodobne o tom vedia viac ako ja, ci autor blogu

[vice]

Vola sa to Interleaving MS Windows optimalizuju ulozenie suborov potrebnych pre boot vzhladom na taketo chovanie a ziskavaju tym na rychlosti. V linuxe su si vsetky subory na disku rovne a takato optimalizacia sa nerobi.

Pokud si vzpomínám, tak interleave byl hitem někdy v době okolo dosu 3.0 či 3.3. Od té doby pokročily diskové technologie poněkud v před. Pokud má disk cache větší než cylindr, tak je interleave IMHO zbytečný.

Nehledě na to, že interleaving byl parametr disku a ne souborového systému, takže mě nenapadá, jak by mohl ms

optimalizuju ulozenie suborov potrebnych pre boot

. Leda že by blbli hlavy zákazníkům, nebo byli šamani. Ale tuším, co je pravděpodobnější.

[Luk]

Leda že by blbli hlavy zákazníkům, nebo byli šamani. Ale tuším, co je pravděpodobnější.

Pokud vím, tak ani jedno z toho. Prostě soubory, se které se načítají při bootu a těsně po něm (je tam, tuším, nějaký časový limit), umístí souvisle na začátek disku. Takže jsou jednak souvislé, a za druhé na začátku (a tedy rychleji načítané). Není v tom žádná magie. Jestli dělají nějaký interleaving, ale opravdu netuším.

[vice]

Není v tom žádná magie. Jestli dělají nějaký interleaving, ale opravdu netuším.

Ale to jsem přece měl na mysli. Není v tom žádná magie, a ani podpora fs.

O.T. Svého času OS/2 přišel s načítáním všech systémových knihoven při startu OS. Dlouho to startovalo, ale pak byly všechny systémové knihovny dostupné v cache (nebo ve swapu ,který se díky nefragmentaci načítal rychleji). MS na to mělo spoustu keců typu "co je to za systém když tak pomalu startuje", až se v (tuším) Office 97 objevilo "Rychlé startování office" - kdo uhodne princip?

Tím jsem jen chtěl říct, že ne všechno je nutně takové, jak to vypadá.

[Michal Kubeček]

Pokud si vzpomínám, tak interleave byl hitem někdy v době okolo dosu 3.0 či 3.3. Od té doby pokročily diskové technologie poněkud v před. Pokud má disk cache větší než cylindr, tak je interleave IMHO zbytečný.

Přesně tak. Interleaving se už nepoužívá asi tak stejně dlouho, jako si uživatelé neprovádějí low-level formát disků a neparkují je, tj. někdy tak od velikosti 40 MB (plus minus nějaké drobné). Navíc interleaving stejně neměl na potřebu resp. užitečnost defragmentace naprosto žádný vliv, protože filesystém pracoval s logickými čísly sektorů, ne s fyzickými (jinak by slučování sektorů do alokačních bloků (clusterů) nemělo absolutně žádný smysl). A ještě do třetice: poměrně dlouho už jsou všechny disky překládané už na úrovni jejich vlastní elektroniky, takže o tom, jak si odpovídají čísla sektorů, která používá software s jejich skutečným fyzickým umístěním na plotnách disku, můžeme nanejvýš tak planě spekulovat…

[Miroslav Suchy]

Vase uvaha ma nekolik nedostatku: - neberete vpotaz, ze po logoutu ty soubory nejspise zustanou v systemove cache a tedy se podruhe nactou rychleji. - to ze i po odhlaseni mohou zustat nejake knihovny stale v pameti (KDE, je rusi az po nejake dobe necinnosti). - vubec ve vasem malem testu nezminujete defragmentaci, kvuli ktere to delate.

Spravny test by mel byt (kdyz uz) start KDE, logout, reset (tj. mereni nebude prvni start KDE) start KDE (zmerit), logout defragmentace, reset start KDE (zmerit)

[Luboš Luňák]

To je umyslne, asi jsem to spatne vysvetlil (no jo, kdyz clovek neco pise podruhe :-/ ).

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

Ale o to snad slo, zjistit jaky vliv ma cteni z disku na start KDE. Rozdil mezi starty pak porovname s maximalni rychlosti cteni z disku a skutecnou potrebou dat KDE ke startu a zjistime, jaky vliv ma motyli let hlavicek nad plotnami disku. Mozna to autor nenapsal sikovne, ale staci se trochu zamyslet co chtel rici.

[Orrorin]

Takže by šel zrychlit boot tak, že by se zjistilo, které soubory jsou při něm čteny, ty by se zkopírovaly do jednoho souboru. Tento soubor by se v nějaké rané části bootování celý nahrál do paměti a místo, aby se soubory četli z disku by se četli z paměti? Při bootu přece moc paměti nespotřebováváme, takže by přítomnost i toho velkého souboru v paměti vadit neměla.

[Orrorin]

Ten soubor by se mohl vytvářet třeba před vypnutím počítače, dlouhé vypínání by mi nevadilo. Ale zrychlení bootování by mi pomohlo - notebook pochopitelně nemohu nechávat běžet pořád.

[Michal Čihař]

Od čeho je suspend?

[Orrorin]

Suspendu nedůvěřuju. Nemám proto sice žádné objektivní důvody, je to spíš psychologická věc. Zdá se mi, že taková věc prostě musí být příčinou různých problémů a nestability.

Jak je to třeba se síťováním? Co když mám IP adresu přidělovanou dynamicky a aplikace si z nějakého důvodu chce pamatovat, jakou IP mám. Pak po probuzení nemusí fungovat, ne? To by možná šlo řešit NATem 1:1 (jedna strana dynamicky přidělovaná, druhá statická privátní), ale v tom se nevyznám.

[trekker.dk]

Zdá se mi, že taková věc prostě musí být příčinou různých problémů a nestability.

No vidíš, není. Jediná aplikace, která se nesrovná se suspendem, je Kopete, které ohlásí chybu při komunikaci s Jabber serverem.

Co když mám IP adresu přidělovanou dynamicky a aplikace si z nějakého důvodu chce pamatovat, jakou IP mám.

Program, který se nevyrovná s tím, že se změnila IP adresa stroje, na kterém běží, si zaslouží spadnout.

Vždyť to se může stát i během normálního provozu, když se DHCP server rozhodne, že přidělí nějakou jinou. (Neměl by, ale může.)

[trekker.dk]

Oprava: která se nesrovná se suspendem -> která se u mě nesrovná se suspendem

[Orrorin]

No vidíš, není. Jediná aplikace, která se nesrovná se suspendem, je Kopete, které ohlásí chybu při komunikaci s Jabber serverem.

Ten Kopete je samozřejmě pochopitelný. Ale ukazuje to jednu věc, že suspend je věc, se kterou se předem nepočítá a se před aplikacemi skrývá. Přitom by bylo docela pěkné, kdyby aplikace mohla dostat zprávu, že se připravuje suspend a nějak se podle toho zařídit - třeba právě se korektně odpojit od toho ICQ nebo jabberu.

Na ten Kopete by se asi dal udělat takový malý skritptík , který by pomocí dcop před suspendem odhásil od ICQ serveru, počítač suspendoval a po probuzení zase hned přihlásil. Ale obecně to udělat nelze.

Přeju ti, že ti to funguje, ale spousta lidí s tím problémy má.

[Josef Kufner]

Jo, tohle je realizovatelné a něco podobného používám při zamykání desktopu – mám script, který nastavý stav Gajimu na Away a po odemknutí zase na to co tam bylo. Pověsit něco podobného na suspend není problém, jen to chce na uspávání používat jen jednu věc.

[David Jaša]

Systémověji by to mělo IMO být přes d-bus (power-manager pošle broadcast o zamknutí nebo suspendu a programy si ten event samy zpracují).

[Josef Kufner]

Ale to by musely nějaké takové programy běžet. V normálním stavu běží akorát acpid, který na event z acpi reaguje spuštěním scriptu. Vrámci desktopu mi neběží nic, co by poslouchalo a reagovalo, takže smůla. Ale jo, chtělo by to nějaký superserver na d-bus, který by reagoval spouštěním dalších procesů (obdoba inetd).

[Michal Čihař]

Tolik paměti většina lidí nemá (pokud za konec bootu považujeme naběhnutí grafického desktopu).

[Luboš Luňák]

Vetsina lidi nema 128M RAM?

[Michal Čihař]

128MB které může zahodit než desktop naběhne ... to se pak zabije víc času swapováním. Neřeším jestli 128MB opravdu stačí...

[Luboš Luňák]

Jenze vetsina z tech predem nactenych dat z disku v pameti prece nakonec zustane.

[Michal Čihař]

No pokud by se to nacpalo do cache tak ano, nějak jsem automaticky počítal s řešením přes ramdisk .

[Orrorin]

Nedokážu odhadnout, kolik by mohlo být potřeba. Je pravda, že desktopová prostředí asi pracují s hodně daty, takže by se to mohlo vyšplhat vysoko.

Jak velká je ten oddíl pro fcache?

[Mikos]

Něco takového na ten způsob už existuje, viz moje zprávička o fcache, čas bootu dokáže zkrátit až o několik desítek sekund (záleží ale samozřejmě na konkrétní konfiguraci). Vytvoří se partition pro fcache (stejně jako je třeba partition pro swap) a v průběhu bootu si zaznamenává v jakém pořadí se data načítají a ukládá je lineárně do té své cache-partition. Při příštím bootu jsou pak transparentně čtena data z té cache-partition (v případě že došlo k nějaké změně tak se ale samozřejmě cache nepoužije) a vede to opravdu k hodně velkému zrychlení bootu (právě díky linearizaci přístupu na disk).

[michich]

Ano, fcache opravdu funguje. Jens Axboe už to ale dál nevyvíjí. Fcache byla podle něj určena jen jako výzkumný projekt. Chystal se začít pracovat na dokonalejším řešení, ale zatím nevím o tom, že by něco zveřejnil.

[Josef Kufner]

IMHO by stačilo vzít atime všech souborů a pouhým překopírováním je umístit na jinou prázdnou partišnu a z té pak bootovat. Soubory by se seřadily podle času přístupu, takže by ležely tak jak budou potřeba a stačilo by říct kernelu, že má z téhle partišny načítat napřed po větších blocích do cache.

Pokud by nestačil atime, mělo by stačit něco ve stylu "strace | grep open" (což asi dělá fcache) a někam si logovat přístupy k disku. Ideální by bylo, kdyby tohle dělal filesystém sám nebo na to měl nástroj, aby nebylo třeba překopírovávat tam a zpět, což navíc není stoprocentní, ale do jisté míry to funguje.

[Mikos]

Mít na desktopu zapnutý update atime je IMHO blbost. Přidání položky "noatime" do /etc/fstab ke všem diskům je první věc co dělám na každé Linuxové instalaci Update atime zbytečně zpomaluje přístup k disku...

A hlavně fcache funguje zcela transparentně (je přímo provázána s ext3, ale podporu by mělo jít jednoduše přidat i k jiným filesystemům), jen se jako boot parametr kernelu předá kde leží cache-partition a to je vše co člověk musí udělat...

[rastos]

Mít na desktopu zapnutý update atime je IMHO blbost. Přidání položky "noatime" do /etc/fstab ke všem diskům je první věc co dělám na každé Linuxové instalaci Update atime zbytečně zpomaluje přístup k disku...

Tak to by mi chýbalo. Relatívne často pátram po tom, či program skutočne našiel konfigurák či vstupný súbor tak, ako si predstavujem. ( ls -ltu )

[Heron]

Update atime zbytečně zpomaluje přístup k disku...

Máš tohle změřené? Přiznám se, že noatime dávám taky všude, ale změny v rychlosti jsem si nevšiml - mnohem větší efekt má (u ext3) větší commit time.

[Orrorin]

A jak se zařídí, aby tím překopírováním bylo uchováno pořadí na disku?

[Josef Kufner]

Základní předpoklad je, že to tam filesystém nějak rozumě naskládá, kdyz bude disk předtím prázdný. Ale jak už jsem napsal, není to jisté a podpora ve filesystému by byla lepší. Narozdíl od fcache by to ale mělo být přímo ve filesystému zkomponováno stejně, jako je obrana proti fragmentaci souborů. Prostě jen další optimalizace. Výhodou je, že by to urychlilo veškeré načítání a mohlo byl to být transparentnější než transparentní.

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

Partition musi byt typu FAT. Pejme pisen dokola ....

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

Vlastne jsem chtel napsat, ze vedro ma ve dne diru

[#Tom]

S tím, že se Windows, pouští rychle, bych si dovolil nesouhlasit. První oficiální verze Windows XP se mi spouštěla (od zavaděče) asi 25 vteřin (disk WD200BB, 20 GB), Windows 98 asi 21 vteřin (start DOSu nezapočítán, disk WDAC21200H, 1,2 GB). Bylo to Pentium II s 256 MB RAM. V obou případech však šlo o velmi ořezaný, v dnešní době nepoužitelný systém.

Běžné instalace obou těchto systémů se pouští i na lepších strojích mnohem déle. Pokud není potřeba tento start několikrát za den opakovat, pak to ani nevadí.

[Harm]

Na notebooku IBM ThinkPad E600 (P2 400MHz, 128MB ram, disk nevim ale je pomaly, max 4200 otacek) startuji w98 15 vterin i se vsemi aplikacemi ktere se spousteji po startu (icq5 atd..). Tak netvrdte nesmysly.. W98 je po instalaci nadherny stabilni system a hlavne RYCHLE startuje a pokud se ten pocitac pouziva pouze k jednomu ucelu (treba prave web a icq) nedam na nej dopustit.

[#Tom]

To není nesmysl, těch mých 21 vteřin je nejkratší čas, který jsem kdy viděl. Ale je možné, že lze W98 ještě nějak omazat, aby se dalo dosáhnout takového času.

[vencour]

Mam dojem, že už jenom počet řezů písma v tom dělá chaos, s komplet nainstalovaným Corelem mi to nabíhalo pomalejš.

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

Nejstabilnejsi system je ten nejmensi. Nejstabilnejsi je 1OS, mozna mne nekdo presvedci, ze 0OS. Problem je, ze jsou k nicemu (maximalne se hodi k patentovemu rizeni).

[blogsm]

Hodně záleží na procesoru a na hdd. Kamarád se mi už chlubil, že na jeho sestavě (2*300Gb raid 0; conore; 2GB ram;) mu windows naběhnou za chvilku. A dokonce je měl i nainstalované za 5 minut. Nevím jestli teda nekecal. A ty windows neměl osekané přes nlite ani nic podobného.

[Michal Kubeček]

Opravdu hezká ukázka demagogie. Tváříte se, že polemizujete s článkem, který se snaží tvrdit, že linuxové filesystémy nepotřebují za obvyklých okolností defragmentaci, protože vzniku fragmentace účinně předcházejí (ponechme teď stranou otázku, zda a do jaké míry je to pravda). Ale místo toho vlastně v celém příspěvku pouze vysvětlujete, proč podle vás (navíc v jedné konkrétní situaci) není důležité, zda je filesystém fragmentovaný nebo ne. Promiňte, ale postup, kdy "roznesete" článek tím, že rozcupujete na kousíčky tvrzení, které v něm vůbec nebylo, považuji za hodně nešťastný.

Nemluvě o tom, že módu nadávat na kvalitu jednoho serveru na druhém (nejste zdaleka jediný, kdo si stěžuje na kvalitu Roota na ABCLinuxu) také moc nechápu…

[Mikos]

Asi si autora nepřesně pochopil (pravda nenapsal to původně úplně nejlépe, ale teď to tam opravil a vysvětlil trochu srozumitelněji i pro ty co ho předtím zcela nepochopili ). On mluví o fragmentaci. Ale né o fragmentaci na úrovni jednotlivých souborů, ale na úrovni celého disku. Tedy to že nelineární čtení dat při bootu či startu KDE je také druhem fragmentace (který se co do výkonu projevuje ještě mnohem vážněji než fragmentace na úrovni souborů) a že to původní článek zcela opomíjí.

[Heron]

Jenomže to co chce autor je nereálné. Nelze stanovit pořadí čtení souborů a udělat z nich nějaký lineární soubor už proto, že možných pořadí čtení pro N souborů je N!.

[Michal Čihař]

Ale to pořadí lze zjistit při bootování a pak podle toho upravit pořadí na disku. Nějak takhle to dělají windows...

[Heron]

Nejsem si jistý, jestli pořadí čtení souborů při bootu je stále stejné, ale ruku do ohně bych za to nedal. Tuším, že nějaká DB konktrolovala / načítala data do cache. Možná by to šlo řešit prefetch binárek a knihoven, ale je otázka jestli by ten výsledný efekt stál za to. Navíc, ušetřit pár sekund na bootu, když se rebootuje párkrát do roka... zdá se mi to zbytečné.

[D-Evil]

To pořadí ale nemusí bejt stejný. Pokud ten soubor neni v cache, načte se z disku a do cache se uloží. Pokud se změní, aktualizuje se. Nevidim v tom problém.

Rebootovat párkrát do roka? Na desktopu? Obávám se, že ani mezi linuxákama takovejch lidí moc nebude. Spousta lidí počítač na noc vypíná, spousta lidí používá dualboot, spousta lidí chce mít aktuální kernel. Sečteno a podtrženo, spousta lidí bootuje i 365x ročně.

[Mikos]

Nemáš pravdu, stavit to jde. Viz fcache, na kterou sem tu již dával odkaz. Myslím že zrychlení bootu až o několik desítek sekund je v celku jasný důkaz

[Mikos]

En, samozřejmě "stanovit"

[Heron]

No ten článek na rootu je zcela mimo i v té anglické versi. Ukázat nulovou fragmentaci na prázdném disku a vysvětlovat, jak linuxový fs (který vlastně?), geniálně vyhledává volné bloky je hezké, ale v praxi stejně k fragmentaci VŽDY dojde, už třeba jen proto, že není k disposici volný blok o požadované velikosti. A tohle by si měli uvědomit ti, kdo šíří nesmysly o tom, že linux defrag nepotřebuje.

[D-Evil]

To v tom článku ale je, autor přiznává, že k fragmentaci (je zřejmě myšlená nějaká významná úroveň) dochází po zaplnění asi 80 procent disku.

[trekker.dk]

Promiňte, ale postup, kdy "roznesete" článek tím, že rozcupujete na kousíčky tvrzení, které v něm vůbec nebylo, považuji za hodně nešťastný.

Ten postup popsal už pan K.Čapek v Dvanáctero figur zápasu perem čili příručka písmené polemiky - figura šestá - Imago

"Například polemizuje se s něčím, co potíraný odpůrce nikdy neměl na mysli a nikdy v tom smyslu neřekl; dokazuje se mu, že je pitomec a že se mýlí, na jakýchsi tezích, které jsou opravdu pitomé a mylné, ale nejsou jeho."

Je to velmi oblíbená metoda místních "diskutérů"

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

A take je velmi oblibena metoda diskuteru nad clankem nepremyslet, coz je light verze toho, ze si jej poradne neprectu. A az jej prectes a az se zamyslis, pak pochopis, ze pan Capek mel na mysli zcela jine pripady polemiky.

[trekker.dk]

Článek jsem četl a ten, na který je odkazováno, taky.

Neodvážím se tvrdit, jaké případy polemiky měl pan Čapek na mysli*, ale v tomto případě nastává přesně to, co je ve figuře "Imago" popsáno: autor blogu potírá autora (překladatele) článku na rootu za něco, co v článku vůbec nebylo.

* Z tvého příspěvku se zdá, že ty to víš, takže by ses mohl podělit s námi ostatními, kteří nedisponujeme jasnovidectvím.

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

Autor puvodniho clanku vyzdvihuje vyhodu ext2/3fs oproti FATu. Pise o tom, jak uzasne je, ze se soubory snazi rozprostrit rovnomerne po celem disku. Jenze uz nepise, ze to vede k fragmentaci na jine logicke urovni (o ktere pise LL, a jejiz efekt nas zajima nemene). Nekde zde zaznelo, ze zrychleni lze dosahnout prostym nakopirovanim souboru na volnou partition presne v poradi jejich cteni. Jenze to je velky omyl. Prave diky one vyzdvihovane vlastnosti ext3fs budou ty soubory pohazene po disku a onen zatracovany FAT je bude mit pekne za sebou. Neboli jinak, neni vsechno zlato, co se trpyti. A to je tak IMO vse co chtel LL rici, zbytek je mimo rozsah tohoto formatu diskuse.

[MJ]

Prave diky one vyzdvihovane vlastnosti ext3fs budou ty soubory pohazene po disku a onen zatracovany FAT je bude mit pekne za sebou.

Primo: Nejspíš je ani FAT nebude mít pěkně za sebou, protože ty soubory sotva vznikly těsně po sobě.

Secundo: Seek na blízkou stopu není zase o tolik rychlejší než seek na vzdálenou. To podstatné je, že se vůbec nějaký seek musí udělat, a v tom je FATka úplně stejná jako kterýkoliv jiný FS.

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

Ad Primo: Budou za sebou, protoze je v tom poradi na partition nakopirujes.
Ad Secundo: IMO se v takovem pripade zadny pohyb hlavicek nekona, protoze se hlavicka na potrebne stope jiz nachazi.
Lze se o to prit, ale to, ze fcache funguje je dukazem toho, ze takovou optimalizaci provadet lze.

[MJ]

Ad Primo: Budou za sebou, protoze je v tom poradi na partition nakopirujes.

A ze které křišťálové koule to zrovna pro tento okamžik správné pořadí vyvěštím?

Lze se o to prit, ale to, ze fcache funguje je dukazem toho, ze takovou optimalizaci provadet lze.

Že se dá něco málo uoptimalizovat, o to se nepřu, jen tvrdím, že je to nepodstatná úspora oproti tomu, co by se získalo optimalizováním na správném místě.

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

Nevim, co tady resime. Proste to existuje, tak co chcete vice jako dukaz. Podivejte se na http://www.abclinuxu.cz/zpravicky/fcache-vyrazne-zrychleni-bootu, ja tomu nerikam 'neco malo uoptimalizovat', ale vyrazne zrychlit. Dal rozvijet tuto debatu asi nema smysl.

[MJ]

Podíval jsem se a myslím, že komentáře pod článkem už říkají vše, co bych k tomu mohl říci já, tj. že základní problém tkví v nabubřelosti všeho, co se při bootu běžné distribuce spouští a že fcache pouze zmírňuje následky a problém samotný neřeší.

Pro zajímavost: jeden z mých domácích Linuxových strojů bootuje (od spuštění initu) 10 sekund a neběží toho na něm zrovna málo. Jen stačilo nahradit startovací skripty něčím rozumnějším a vyhodit zbytečnosti.

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

Ty si flamer jedna basen. Bez tedy radeji poradit vyrobcum dister jak se delaji spravne boot sequence a take LL, jak ma efektivne startovat KDE. Ale nesnaz se prosim rozporovat funkcni princip fcache.

[MJ]

Bez tedy radeji poradit vyrobcum dister jak se delaji spravne boot sequence a take LL, jak ma efektivne startovat KDE.

Kupodivu tohle už delší dobu dělám: dal jsem dohromady projekt SSS (náhrada rc-skriptů), zde jsem navrhoval paralelní otevírání souborů a tak dále. Zato od vás jsem moc konkrétních návrhů neviděl :)

Ale nesnaz se prosim rozporovat funkcni princip fcache.

Snažně prosím, přečtěte si pořádně, co jsem psal. O funkčním principu fcache nepadlo ani slovo, naopak byla řeč o tom, že to, co fcache dělá, dělá dobře, ale že foukání do horké kaše není všechno.

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

Napsal jste, ze urceni sekvence pristupu k souborum je vesteni z kristalove koule. Fcache tedy funguje prestoze vesti z kristalove koule. Uzasna nahoda. Co se tyce SSS hodne stesti.

[MJ]

Napsal jste, ze urceni sekvence pristupu k souborum je vesteni z kristalove koule. Fcache tedy funguje prestoze vesti z kristalove koule.

Pokud vás zajímá pouze optimalizace bootování, tak funguje (nějak). Já se snažím vidět dál a optimalizovat celkově běh systému. Tam vám tak primitivní křišťálová koule nestačí.

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

Clovece, vzdyt vy ani nevite co to je kristalova koule

[MJ]

To, samozřejmě, jako správný C.W. musím vědět

Zato vám, zdá se, už před nějakým časem došly argumenty

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

Priznavam

[MJ]

Zaslouží si opravdu tolik pozornosti první spuštění nějakého programu? Není přeci jen něco pravdy na staré moudrosti pravící, že Unixový stroj se rebootuje pouze při živelných pohromách? A není pro domácí počítače, které chce majitel vypínat, daleko lepší vykašlat se na všechny ty divoké optimalizace access patternů a preloady (které jsou ve své podstatě nutně věštěním z notně upatlané křišťálové koule) a prostě při shutdownu kompletní stav systému vydumpovat na disk a při startu ho zase na jedno lineární čtení z disku natáhnout?

[MJ]

Ještě drobný dodatek:

Jistě by bylo lepší, kdyby filesystémy rozložení souborů nějak optimalizovaly, jenže jaksi nikdo neví, jak to udělat jednoduše, a než se pouštět do obludností, je lepší optimalizovat jinde.

Například by bylo dosti přímočaré, aby aplikace kernel místo o konkrétní soubor požádaly rovnou o množinu souborů, které budou potřebovat, a kernel je mohl natáhnout v optimálním pořadí.

[Heron]

Jak optimalizovali? FS ukládání dat optimalizuje (podle tvůrců) dostatečně, např. vhodným výberěm volných bloků.

Například by bylo dosti přímočaré, aby aplikace kernel místo o konkrétní soubor požádaly rovnou o množinu souborů, které budou potřebovat, a kernel je mohl natáhnout v optimálním pořadí.

Hmm, nemá tohle spíš řešit cache na řadiči / disku? - rozumné uspořádání pořadí čtení sektorů z disků, něco už je v NCQ.

[Michal Vyskočil]

FS ukládání dat optimalizuje (podle tvůrců) dostatečně, např. vhodným výberěm volných bloků.

No a podle aplikačních programátorů (jakým je Luboš) ne

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

Promin, ale pokud konkretni aplikace privlastku 'aplikacni' znamena 200% boost startu prostredi, pak je to v poradku. Nevim o nicem, co by snad defragmentace filesystemu na urovni sekvence pristupu k souborum mohla pokazit. Vim jen jedno. Az random access memory nahradi sekvencni pametova zarizeni, potom bude tento flame off topic.

[Michal Vyskočil]

Co to znamená "200% boost startu prostředí"? Já jenom polemizoval s Heronem, který je přesvědčen o všemohoucnosti cache disku. Defragmentace filesystému na úrovni sekvence přístupů k souborům (pokud to značí sekvenční přístup k souborům) asi nic nepokazí, maximálně tu sekvenci trochu zrychlí

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

Pak jsem te spatne pochopil, mel jsem za to, ze nazor programatora zlehcujes, protoze se jedna o aplikacniho programatora. Mel jsem si tvou vetu uzavrit do <noirony>. Jinak 200% boostem jsem myslel, ze KDE nabehnou za 12s a ne za 25s (coz je presnejsi vyjadreni vety 'maximálně tu sekvenci trochu zrychlí')

[Michal Vyskočil]

Aha, zase jsem chytřejší

[Heron]

Heron o tom není přesvědčen .

Je pravda, že malé soubory fragmentované (většinou) nejsou, ale jejich čtení je chaotické. To že nějaký program při svém startu načítá desítky knihoven a třeba stovky datových souborů ale není chyba ani diskové cache, ani jádra (takže psát nějaké ad-hoc optimalizace čtení souborů do jádra mi přijde nešťastné), ale je to "chyba" toho programu. Chyba v uvozovkách proto, že takové rozdělení souborů zase může mít jiné výhody (a ten malý soubor může zůstat v diskové cache ).

[Michal Vyskočil]

Myslím, že zmenšení nutnosti seekování při startu aplikací ničemu neuškodí .

[MJ]

Kdyby nic nestálo, tak samozřejmě neuškodí. Jenže jak říká staré přísloví, zadarmo je jenom sýr v pastičce na myši. Zatím nikdo nenavrhl, jak takovouhle optimalizaci udělat jednoduše a přímočaře, takže stojí minimálně nějaké netriviální úsilí, které by bylo možné vynaložit efektivněji a optimalizovat něco, co má větší smysl.

[MJ]

Hmm, nemá tohle spíš řešit cache na řadiči / disku? - rozumné uspořádání pořadí čtení sektorů z disků, něco už je v NCQ.

Nemůže, protože nedokáže vyvěštit, jaká data aplikace bude potřebovat.

Pokud aplikace čte soubory postupně, pak prostě kernelu/řadiči/disku/... nezbývá než nejdříve najít jeden soubor, až bude hotový a aplikace si řekne o další, tak najít druhý a tak dále. Na tom se těžko dá něco zrychlit, leda že by se systém pokoušel věštit, jaké requesty přijdou příště. Jenže to bude sotva něco jiného než ošklivý hack, který bude fungovat jen ve speciálních případech.

Smysl tedy spíš dává naučit aplikace, aby jádru předaly více požadavků najednou a daly mu tak více prostoru k optimalizacím.

[peter_h]

Kedze sa mi nechce citat vsetky tie posty, tak sa necudujte

Takze:
Pisem skoro vsade, ze defragmentacia je O NICOM pokial defragmentacny program hodi jeden subor aplikacie na jeden koniec disku a druhy na opacny, o com bola zmienka v blogu. Defragmentacia je dolezita na rychly zapis a citanie streamu dat (nahravanie videa, napalovanie iso atd), ale vacsina ludi od toho ocakava zrychlenie systemu. Lenze o tom je readahead, zrychlenie sa dostavi az po vazne brutalnej fragmentacii.
Je dobre vediet, ze defrag vo windows98 defragmentoval aj na zaklade nejakych statistik (a ked si po defragmentacii win defragom clovek pustil nortona, tak mal cely disk fragmentovany). Mam dokonca silne podozrenie, ze windowsy si v pripade FAT nacitaju velku cast FAT do pamate, pretoze maju pristup na disk velmi rychly aj v pripade prveho nacitania adresara (FAT je relativne mala). Toto som pod linuxom zatial nepostrehol. Linux ma jeden problem, ze sa snazi byt moc univerzalny ale nasadenie na desktope a na serveri sa lisia.
Dalsia vec - pod linuxom existuje defrag (teda podla fs), asi si niekto nedal tu namahu len tak, lebo sa nudil.
Co by som bol vemi rad, keby bol pod linuxom vyrieseny online defrag. Normalnym ludom clovek nevysvetli, ze potrebuje boot CD atd.
Posledna vec - vie mi niekto vysvetlit, naco je dropcaches? (/proc/sys/vm/ alebo tam niekde)

[Mikos]

Defragmentace (a dokonce zcela nezávislá na filesystemu) pro Linux existuje (a můžeš jí mít spuštěnou kdy chceš, je to na aplikační úrovni, ne na úrovni filesystemu). Jen je potřeba mít na daném filesystemu volné místo alespoň o velikosti největšího souboru. Můžeš dokonce defragmentovat jen jednotlivé adresáře. Ten defragmentační program se jmenuje Shake (a vychází ze staršího skriptu defrag od Cona Kolivase).

[Smazáno]

Už mi s tím vyperte bielizeň! (či jak to bratia slováci nazývají)

Každej, kdo si myslí, že kvalita systému je dána časem mezi zapnutím a přesýpacíma hodinama na ploše je prachsprostej búútovač a nic než čekání si nezaslouží!

Zvlášť když u toho celej říčnej postává se stopkama a ještě podle toho posuzuje kvalitu konkurenčního serveru podle pochybnejch článků převzatejch z kontroverzních webíků, jen aby zpochybnil filesystém o kterým vlastně ani nic neřekne...

(A to ani nemluvím o tý povodni u Kounova mladá pani, ta tenkrát způsobila přepsání celýho memory manadementu)

[peter_h]

Nie kazdy ma zapnuty pocitac cely den. Kolkokrat sa mi stalo, ze som si rano potreboval rychlo nieco vytlacit, radsej som bootol do windows. Prave aj o tom je kvalita systemu, ze by sa to dalo urychlit, ale jadro na to nema vyhovujuce volania.
My sa tu bavime o desktope, chapes?! Desktop, to znamena ze mas k pocitacu pripojenu obrazovku a mys a robis pod X11.
A to s tou bielizňou som ešte nepočul, asi nejaka perla zo stredného slovenska .

[#Tom]

Když to chci mít spuštěný jo rychle, protože chci něco vytisknout, tak si na to vezmu příkazovej řádek a s nějakýma Xkama se vůbec nezatěžuju. Zpravidla ale na to pak spěchám jen proto, že jsem vůl a neumím si správně seřadit ranní činnosti. Pokud mezi ně budou patřit krátké dodělávky na počítači, budu stroj zapínat nejpozději [...] minut (každý si doplní svůj čas) před tou dodělávkou.

[Filip Jirsák]

U desktopového počítače považuji za ideální stav to, že jej nevypínám, ale "uspávám". Takže připravenost systému k práci není problém rychlosti bootování, ale funkčnosti uspávání počítače do paměti a na disk (a jeho probuzení). Kdyby tohle 100% fungovalo (podle toho, co všude možně čtu to tak asi není), není potřeba počítač s Linuxem bootovat vůbec, resp. jednou za čas. (Ve Windowsech mi sice obojí uspávání funguje, ale přesto počítač radši denně nebo jednou za dva dny vypínám, protože se tím aspoň ukončí polomrtvá obslužná utilita nVidia grafické karty…)

[happy barney]

optimalizovat bootovanie? pri hustote 3 krat rocne je to vskutku vyznamna uspora casu
nevraviac o tom, ze z celkoveho casu bootovania najviac casu (plati na mojom pocitaci) zoberie cakanie na periferie.

[Mikos]

Budeš se možná divit, ale spousta lidí bootuje každý den, někdy i častěji. Né všichni nechávají běžet desktop neustále, někdo nechce či ani nemůže...

[Heron]

...ani nemůže?

Ještě jsem neviděl komp, který by nemohl běžet nonstop. Btw všechny moje kompy (dva doma + v práci), nonstop běží a nezaznamenal jsem žádný problém. Naopak bych řekl, že pro HW je to vhodnější.

[#Tom]

Neodhlučněné počítače by neměly běžet nonstop, kdo to má při spaní poslouchat?

[Heron]

Tak zastav ventilátory .

[#Tom]

Ty nejsou tak hrozný. (Originální větrák z procesoru jsem vyhodil a dal jsem místo něj nový za 40 korun a ten ve zdroji je zatím docela tichý. ) Když už mi to jede v noci, tak vypínám starej 1,2 GB disk WDAC21200H, polovina kraválu zmizí. Jednou ty disky vyhodím všechny a dám tam místo nich compactflashku.

[Heron]

Pravda, spát u hučícího kompu není zrovna OK a investice do ztišení kompu je velká (vím o čem mluvím). Vůbec nejlepší je bezdisková stanice s kvalitním větrákem a pasivně chlazenou grafikou napojená na (file)server, který bude v jiné místnosti. Komp by byl prakticky neslyšitelný - navíc by nebyl problém ho na noc vypínat, protože všechny služby by řešil server.

[peter_h]

Naopak bych řekl, že pro HW je to vhodnější.

No po roku behu jedneho kompu s WD diskom hucal ako kosacka, ostatne PC co mali ten disk nebolo ani pocut, tak neviem ci to je vhodnejsie.
A okrem toho ja mam komp pri hlave, tak neviem ako by som pri nom spal.

[Harm]

Vhodnejsi to urcite nebude, napriklad zivotnost harddisku se meri v hodinach, takze jestli bezi 16 hodin a 8 odpociva nebo bezi 24 je opravdu velky rozdil... Stejne tak ventilatory, jejich loziska maji taky omezenou zivotnost, a to nemluvim o spotrebe el. energie. A suspendu neverim, s mym pocitacem nefunguje ani v linuxu ani ve windows...

Ještě jsem neviděl komp, který by nemohl běžet nonstop.

Nekdo ma pocitac v mistnosti kde spi a vadi mu i zapnute reproduktory a nemuze pri nich spat.. (pokud v tichu nic neslysite prilozte ucho az k reproduktoru, nekteri citlivejsi lide tento sum slysi i pres celou mistnost. Tolik k pocitacum co nemuzou bezet nonstop

[Filip Jirsák]

Vhodnejsi to urcite nebude, napriklad zivotnost harddisku se meri v hodinach, takze jestli bezi 16 hodin a 8 odpociva nebo bezi 24 je opravdu velky rozdil... Stejne tak ventilatory, jejich loziska maji taky omezenou zivotnost, a to nemluvim o spotrebe el. energie. A suspendu neverim, s mym pocitacem nefunguje ani v linuxu ani ve windows...

Nikdo nemluví o tom, že ten počítač má fyzicky běžet pořád. Ale právě o tom suspendu. No a jestli nefunguje suspend, tak je správné řešení opravovat suspend, ne řešit, jak co nejrychleji bootovat. Ono při tom řešení rychlého bootování se postupně přijde na to, že se opakují stále stejné operace, které dávají stejné výsledky, a že by se hodilo ukládat i části RAM. Pak se zjistí, že po bootu do čistého window manageru musí člověk stejně spouštět programy a otevírat dokumenty, a že to je taky operace, která proběhla už po minulém bootu – a že by se tedy hodilo ukládat celou RAM i stav procesů. A ejhle, vymysleli jsme suspend…

[Harm]

a že by se tedy hodilo ukládat celou RAM i stav procesů.

a uz zase mame to pc zapnute, a zase nam bzuci, sumi nebo co.. a tomu se a to spousta lidi nesnese, suspend je uzitecny na notebooku pro setreni energie, na destkopu taky, ale ne v mistnosti kde spi lidi..

[miso]

suspend je uzitecny na notebooku pro setreni energie, na destkopu taky, ale ne v mistnosti kde spi lidi..

suspend to disk a suspend to ram su dve rozdielne veci
pochybujem, ze by spiacim ludom vadil suspend to disk ...

[Harm]

U suspend to disk se pocitac "vypne" uplne?? (tzn z ho muzu odpojit z el. site a nic se nestane?)

[miso]

Ano - ja takto vypinam notebook, pretoze je to rychlejsie.

[Filip Jirsák]

a že by se tedy hodilo ukládat celou RAM i stav procesů.

a uz zase mame to pc zapnute

suspend-to-disk – celá RAM a stav jádra a procesorů a procesoru a všeho možného se uloží na disk a počítač se vypne, odpojí od proudu a harddisk si vymontujete a dáte pod polštář

suspend-to-ram - stav jádra, procesů atd. se uloží do RAM, počítač se přepne do stand-by režimu (stejný režim, v jakém je dnes běžně počítač, pokud je vypnutý), akorát zůstane napájená RAM – na to rozhodně nejsou žádné větráky potřeba

[Harm]

suspend to disk - nic takoveho pod win neni takze sem po tom nepatral ani pod linuxem, moje chyba...

suspend to ram - zustane napajena ram, nekomu to fakt vadi.. me osobne ne, ale znam lidi kteri maji pocitac napojeny na prodluzku s vypinacem a kdyz jdou spat tak ho vypinaji - nemohou pritom usnout, i klasicka zarovka pry vydava nesnesitelne bzuceni :)

[Heron]

Suspend to disk ve Windows je a to pěkně dlouho. Suspend to ram musí umět základní dneska (resp BIOS).

[Filip Jirsák]

V českých Windows XP se suspend-to-ram jmenuje "Přepnout do úsporného režimu" a suspend-to-disk "Přepnout do režimu spánku". Ovšem musíte mít na HDD volné místo minimálně o velikosti RAM, aby bylo kam tu RAMku uložit

Dnešní ATX desky nejsou na dlouhodobé odpojování od sítě stavěné, baterky na udržení času a dat pro BIOS nestojí za moc. Já osobně nechávám PC pod proudem neustále, pouze pokud se blíží bouřka, tak je odpojím.

[Josef Kufner]

Nemají bootovat, mají probouzet. Pokud jim probouzení/uspávání nejde, mají hlásit bug. Bootování do toho netahej, to s dobou tma–desktop nemá nic společného.

[repli]

Sice windows plocha naběhne dřív, ale stejne nemáte šanci udělat nic... prostě ješte tak přes půl minuty chroustá disk.. takže tohle jsem započetl do startu taky a hned je na tom linux s KDE lépe.