Miroslav Lachman wrote on 04/18/2016 18:36:
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.
S vetsim mnozstvim dat a s testem, ktery trval pres 5 hodin (vcetne
kopirovani dat) uz je rozdil viditelny, ale je to zhruba jen 10%.
Oddil mel v obou pripadech 3.7TB a data na nem zapsana 381GB
Pro prvni test bylo pouzito
# newfs -U -b 64k -f 8k -i 64k /dev/mirror/gm1p8
(newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 8192 -f 8192 -g 16384 -h 64 -i
65536 -k 16720 -m 8 -o time -s 7704983136)
time fsck:
1107.66 real 10.03 user 5.84 sys
A pro druhy defaultni hodnoty
# newfs -U /dev/mirror/gm1p8
(newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i
8192 -k 6408 -m 8 -o time -s 7704983144)
time fsck:
1226.20 real 13.08 user 6.08 sys
Takze je to zhruba rozdil 18 vs 20 minut.
Zajimave jsou i casy rozbalovani tar archivu (byl to 17GB archiv, ktery
se rozbaloval 21x)
Prumer pro optimalizovany fs
avg real: 359.907 user: 2.88842 sys: 21.5595
Prumer pro defaultni fs
avg real: 365.21 user: 2.99632 sys: 19.7974
Optimalizovany je o 5 sekund realneho casu rychlejsi, i kdyz potreboval
vic sys casu.
A jeste poznamka o zabranem mistu - "optimalizovany" fs spotreboval o
12GB mista navic pro uchovani stejneho mnozstvi stejnych dat.
Doufam, ze se tenhle maly vyzkum bude taky nekdy nekomu hodit. Pro me z
toho vyplyva, ze pro tento typ dat se optimalizace az tak vyrazne
neprojevila. Kdyby tam bylo vetsi mnozstvi souboru vetsich nez stovky
kilobytu, pak by se to asi vyplatilo vic.
Mirek
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
