fragmentace disku

[Míla Kuchta]

9r na seznam.cz wrote:
>> Ja bych si treba predstavoval neco, co ma v sobe nejak zamontovan MS
>> soft.
>> Nevim sice, jak to presne v nem funguje, ale system si pri spousteni
>> aplikace dokaze zapamatovat poradi natahovanych souboru a pak by mel
>> teoreticky dokazat soubory preskladat tak, ze by se mely taha rychleji.
> 
> to opravdu existuje? selsky rozum rika udelat filesystem tak, aby bylo
> co nejrychlejsi nacteni souboru. pokud aplikace vyuziva 50 malinkatych
> souboru vytvorenych s rucnym casovym odstupem a proto lezicich na
> ruznych castech disku, tak pri postupnem nacitani trosku seeku opravdu
> pribyde.

Jak znam MicroSoft, tak bych se ani nedivil, ze neco takoveho pouziva,
ale pravdepodobne, jako obvykle, to bude druhu: neco takoveho to dela,
ale o vyslednem efektu a cistote tohoto reseni je mozno silne
pochybovat.

>> Nedelam si iluze, ze by tohole nejak slov jednoduse vmontovat do linux 
>> ale presto - takovy counter pouzivanosti souboru a nasledne
>> background-ove
>> pretrasani disku by me vubec nevadilo - a zrychleni by tam urcite bylo
>> uz jen z toho duvodu, ze cim blize k zacatku disku tim se data sypou
>> rychleji.
> 
> to opravdu plati? mozna na nepouzitelnych systemech pouzivajicich
> progresivni technologii fat, kdy je treba neustale seekovat na zacatek
> (do fatky) a pak k datum samotnym. vyhodou vsak je, ze uzivatel muze
> odcizeni disku identifikovat sluchem...

Ne, to podle selskeho ruzumu neplati:-). AFAIK uz od dob HPFS, z
ktereho NTFS vychazi, jsou directory tables a ostatni popisne
informace ulozeny v pravidelnych intervalech a na stredu disku a disk,
jak znamo, ma stejnou hustotu zaznamu v poctu sektoru na stopu po
celem obvodu. Takze naopak umisteni souboru na stred by mohlo mit
kyzeny efekt (vzdy bude nutne posunout hlavu maximalne o pul delky a
nebude dochazet k diskriminaci okrajovych cylindru v pripade pouziti
algoritmu typu SSF.

> 
>> trosku pomaleji. Mozna by bylo nejlepsi kdyz bych si sam rekl nejakou
>> preferenci
>> rozmisteni adresaru - neco jako ma Norton Disk Speed.
> 
> takoveto prasarny imho urychluji praci tim, ze "obchazeji" konkretni
> chyby konkretniho fs. pokud ext2 tyto chyby nema, nemuzete je obejit 
> a tim padem ani zrychlit praci.

Nerekl bych ze se NTFS a ext2 v principu tolik lisi.

> obecne sice pristup k datum lze urychlit tim, ze si je na disku vhodne
> preskladate, ale ta vhodnost silne zavisi na konkretni situaci. o
> vyuziti by slo uvazovat mozna u nejakeho silne specificky vyuzivaneho
> systemu, kde by pripadne zrychleni bylo zanedbatelne, na unixovem
> systemu by jste imho usetril min casu nez kolik by zabralo rozhodovani o
> "spravnem" miste
> a az by konecne byly soubory tam, kde je aplikace precte nejrychleji,
> tak byste je stejne zalohoval a pak by byly tam, kde je nejrychleji
> precte vas archivacni program...

Souhlas.

> 
> v zadnem pripade vsak zrychleni nebude srovanatelne s tim, ktere ziskate
> pri prechodu z fat/ntfs na normalni filesystem.

FAT a NTFS bych do jednoho pytle nehazel, i kdyz mam alergii na
radobyinvencniagenialni reseni MicroSoftu.

S pozdravem

Mila Kuchta