Portál AbcLinuxu, 30. dubna 2025 16:51
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.
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.
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.
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.
6.9.2006 23:06
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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ů).
7.9.2006 01:27
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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ší.
5.9.2006 23:46
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
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.
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á.
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…
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.)
, 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á.
5.9.2006 19:00
Josef Kufner | skóre: 70
6.9.2006 18:59
Josef Kufner | skóre: 70
.
5.9.2006 15:08
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
5.9.2006 16:05
michich | skóre: 51
| blog: ohrivane_parky
5.9.2006 19:09
Josef Kufner | skóre: 70
5.9.2006 19:16
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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...
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 )
6.9.2006 07:50
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
5.9.2006 19:45
Josef Kufner | skóre: 70
5.9.2006 16:40
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
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š.
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…
5.9.2006 17:18
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
). 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í.
5.9.2006 17:32
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
5.9.2006 17:42
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
5.9.2006 18:20
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
5.9.2006 17:23
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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ů"
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.
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ě.
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.
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čí.
Zato vám, zdá se, už před nějakým časem došly argumenty
5.9.2006 20:00
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
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
6.9.2006 10:25
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
.
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 ).
.
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.
Takze:
6.9.2006 00:32
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
.
6.9.2006 16:53
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
6.9.2006 17:17
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
...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ší.
6.9.2006 21:05
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
.
) 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.
8.9.2006 16:34
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
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 nonstopJeště jsem neviděl komp, který by nemohl běžet nonstop.
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…
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..
suspend je uzitecny na notebooku pro setreni energie, na destkopu taky, ale ne v mistnosti kde spi lidi..
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ářa že by se tedy hodilo ukládat celou RAM i stav procesů.a uz zase mame to pc zapnute
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
9.9.2006 08:14
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
6.9.2006 19:09
Josef Kufner | skóre: 70
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.