IMHO pri >=90% fragmentácii (takmer) absolútne nezáleží od použitého FS (až na nejaké obstarožné výnimky). Alokátor sa snaží uložiť bloky rovnakého súboru (súbory v rovnakých adresároch a iných kritérií, závisí od alokátora) blízko seba. Blízko seba môže znamenať aj s fragmentáciou (paradoxne tak súbor fragmentovaný na viacej častí môže byť rýchlejší na čítanie než súbor rozdelený na menej častí, pri ktorých disk musí seekovať ďalej, čo nastáva práve pri veľmi zaplnenej partícii).
Druhá vec: s výnimkou "tlačenia" súboru max. rýchlosťou (napr. kopírovanie, čo nie je moc časté), medzi dvoma prístupmi k súboru od jedného procesu/vlákna stihne disk zaseekovať niekoľkokrát kvôli requestom od ostatných procesov, tam už nejaká fragmentácia extrémny rozdiel nehrá (ak neni 4gigový súbor rozsypaný jak čaj po celom disku).
Nakoniec, pri čítaní mnoho menších súborov (<=20k) je skoro absolútne jedno jak moc sú fragmentované (pr. portage), tam skôr spraví rozdiel
-jak moc blízko sú (prefetch sektorov/blokov do cache)
-či sa po readdir() najprv zotriedia podľa mena (typicky tak nebudú zotriedené podľa inodov/umiestnenia na disku, tiež závisí jak sa vytvárali)
Nejde ani tak moc o fragmentáciu ako skôr o to, že by alokátor potreboval nejaké hinty, jak sa k súborom bude v budúcnosti pristupovať, aby ich nejak "inteligentne" zoradil. Reiser4 a XFS (myslím že aj reiserfs) odkladajú preto alokáciu do posledného možného okamžiku. Ext3 má zase špeciálny atribút na adresáre, ktorým sa mu dá povedať, že má súbory v ňom naopak rozptýliť než držať dokopy (typicky pre home, ale dá sa to nastaviť explicitne aj pre iné adresáre) - zmysel toho je v tom, aby bolo dosť miesta v blízkosti jednotlivých podadresárov (home adresáre rozličných užívateľov nie sú typicky korelované).
Trochu podobnú vec ext3-ovskému rozptylu robí XFS filestreams alokátor pre súbory ak sa očakávajú veľké súbory (nahrávané streamy), snaží sa každý hodiť do osobitnej alokačnej skupiny; nastavuje sa to podobne cez chattr. Ten alokátor sa zase ale nehodí na "bežné použitie FS", hlavne kvôli predlžovaniu (xfs má ďalšie dva alokátory a naviac sa snaží rozhodiť nové adresáre do iných alokačných skupín, z podobného dôvodu "aby mal dosť miesta okolo").
Záver: rozličné metódy jak dostať z FS maximum existujú, ale ich použitie neni úplne triviálne (alokátor ani I/O scheduler nemajú krištáľovú guľu ;-)) Nakoniec najviac spraví cache - radšej dokúpiť väčší disk aby nebol plnší než dajme tomu 80% (menšia pravdepodobnosť fragmentácie, alokátor lepšie vyberá bloky), RAM (viac cache), rozsypané a často sa meniace veci hodiť do tmpfs.
Odpověď na názor
Odpovídáte na názor k článku Defragmentace disků v Linuxu.
Pravidla pro diskutující
Přidáním čtenářského příspěvku do diskusí či fóra souhlasíte s tím, že budete dodržovat následující pravidla. Při jejich hrubém porušení se vystavujete riziku smazání příspěvku, jeho modifikaci, v krajním případě i zablokování přístupu do diskusí.
Redakce ze zásady nezasahuje do čtenářských diskusí a zavazuje se, že nebude mazat ani modifikovat příspěvky, kromě případů, kdy tyto porušují některé z následujících pravidel. V takové situaci je na zvážení redakce, zda příspěvek modifikuje s viditelným upozorněním, či přímo smaže. Redakce nikdy nemaže „nesouhlasné komentáře“ jen proto, že jsou nesouhlasné. Vítáme střet názorů, ale vždy v rámci slušné a kultivované debaty.
Příspěvky nesmí obsahovat:
- Vulgární či hrubé výrazy.
- Urážlivé výroky na adresu druhé osoby či skupiny osob.
- Texty, které mají za cíl jen vyprovokovat emotivní reakci (trolling).
- Rasové útoky či útoky na jakoukoliv jinou menšinu či skupinu obyvatel.
- Komerční nabídky a affiliate odkazy.
- Odkazy na warez, sériová čísla, licenční kódy, pornografii a další nevhodný materiál stejně jako žádosti o poskytnutí tohoto obsahu.
- Prokazatelně protiprávní obsah.
Informace o soukromí: U všech přidaných komentářů provozovatel ukládá IP adresu a hostname odesílatele. U neregistrovaných uživatelů se na webu zobrazuje část hostname, případně IP adresy, neumožňující identifikovat konkrétní počítač.
Povolené značky XHTML: a, br, code, em, li, ol, p, pre, strong, sub, sup, ul
