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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
