zvetseni gmirroru a optimalizace newfs

[Miroslav Lachman]

Dan Lukes wrote on 04/18/2016 15:26:
>> Zustanou tyto proporce zrychle platit i pro zaplneny filesystem?
>
>
> I tohle muzes vyzkouset - ani na to jak rychlost fsck ovlivnuje pocet
> pouzitych inode a velikost souboru nepotrebujes realny 4TB disk. To se
> da otestovat i na mensim svazku. Aboslutni hodnotu budou jine, ale
> vzajemny pomer by mel byt podobny.

Tak zrovna v tomhle "real world" prikladu se ukazalo, ze tam je rozdil 
nemeritelny.

8.49s vs 8.05s je spis odchylka mereni.
Ten prvni cas je pro 32/4, druhy pro 64/8. Zkousel jsem to na 16GB 
oddilu zaplnenem 3.7GB skutecnych dat.

Pri kopirovani dat se navic ukazalo, ze ta prumerna velikost je hodne 
ovlivnena tim, ze je tam par obrovskych souboru a k tomu hromada mensich 
v rozsahu 3kB - 90kB. Takze i kdyz na tomhle zmensenem prikladu vychazi 
vypocitana prumerna velikost 90kB, vetsina souboru je pod 90kB.

Zkousel jsem to jeste na tomhle malem oddilu porovnavat s malymi soubory 
(rozbalit ports.tar.gz) a pak delat fsck.
Pro 64/8 trva rozbaleni o 5 sekund dele (zrejme proto, ze se kvuli 
vetsim fragmentum a blokum zapisuje na disk vice dat).

A podobne je tomu i s fsck:
64/8  8, 16, 25 sekund
32/4  6, 12, 18 sekund

ty casy jsou pro 1, 2 a 3 rozbalene ports tree (v ruzne pojmenovanych 
adresarich)

Pro uplnost jeste uvedu, ze fsck prazdneho oddilu probehlo okamzite, asi 
za 0.05 sekundy.

A kdyz jsem pro 64/8 variantu zkousel 1M inodu a 100k inodu, tak fsck se 
porad drzelo okolo tech 8 sekund.

Takze jsem zase na rozpacich, jestli ta optimalizace newfs ma smysl pro 
tenhle pripad.
Asi to jeste vyzkousim na vetsim oddilu s vetsim mnozstvim dat.

Mirek