zvetseni gmirroru a optimalizace newfs

[Miroslav Lachman]

Dan Lukes wrote on 04/14/2016 23:20:

> Popsany problem nastaval jen u "prasacke konfigurace", kdy se nejdriv
> pokusis udelat GPT pres cely disk a pak nad nim udelat gmirror, takze se
> tyhle dve struktury prekryvaly.
>
> Kdyz se to udela korektne, tedy GPT se dela az uvnitr gmirroru, tak se
> to prekryvat nemuze.
>
> Jestli to z toho bootuje nevim, uz jsem to dost dlouho nezkousel.

Uz si matne vybavuju, ze ten problem neni tak uplne problem FreeBSD, ale 
HW. I kdyz tu konfiguraci gmirroru udelas spravne a disky nejprve vlozis 
do mirroru a pak je rozdelis GPT, tak disk ma v poslednim sektoru 
metadata gmirroru, ale nektere motherboardy odmitnou nabootovat, pokud 
se neshoduje obsah primarni i zalozni tabulky toho GPT. Takze i kdyz by 
z toho system byl schopny nabootovat, tak se k tomu system vubec 
nedostane a zarizne to hned "firmware" toho boardu.

>> Da se jeste neco udelat pro rychlejsi fsck?
>
> Zmensit pocet inode. Option -i. Defaultni hodnota vychazi z pomerne
> hodne male hodnoty prumerne velikoti souboru a vede k vysokemu poctu inode.
>
> Tohle nemusime resit jako teoretickou ulohu. i kdyz nemas 4TB disk na
> pokusy - staci pokud volnych mas cca 1.5GB.

Ty disky uz tady mam a zatim jsem je nenasadil, takze jsou v testovacim 
stroji, abych si s tim pohral. Udelal jsem nad nima gmirror a pak 
rozdelil na oddily, jake to bude mit i v produkci. Ten posledni oddil, 
ktery bude slouzit pro ukladani dat, jsem pak zkousel potrapit ruznymi 
kombinacemi options pro newfs

> Zkousel jsem to velice lehce, ale zda se mi, ze byses mel vratit k uvaze
> o zvetseni bloku na 64k/8k - z hlediska rychlosit pristupu na disk to
> sice asi az takovy vliv nema, ale na fsck to, zda se, vliv ma pomerne
> velky.

Ano, tohle ma na fsck prazdneho disku ten nejvetsi vliv ze vsech 
zkousenych moznosti.

Pro zajimavost pridavam vysledky:

Defaultni 32k/4k - fsck za 43 sekund
Upraveno na 64k/8k - fsck za 14 sekund

Pak jsem jeste zkousel upravovat pocet inodu, protoze defaultne jich tam 
je 482M (pri 32k/4k) nebo 241M (pri 64k/8k)
Zkusil jsem to pomoci -i 128k dostat na 30M inodu a fsck se zkratilo:

32k/4k -i 128k (30M inodu) fsck za 32 sekund (misto 43)
64k/8k -i 128k (30M inodu) fsck za 11 sekund (misto 14)

Soucasny produkcni FS vypada takto
# df -i -t ufs /vol1
Filesystem          1K-blocks       Used    Avail Capacity iused 
ifree %iused  Mounted on
/dev/mirror/gm0s2f 1870203712 1697619120 97776444    95% 9648452 
109130426    8%   /vol1

Pri zdvojnasobeni kapacity a casem i ulozenych dat bych se mel pohybovat 
nekde okolo 20M inodu a tak by tech 30M melo stacit, ale nechci to zase 
moc riskovat a tak jsem zkousel jeste "-i 96k" pro 40M inodu a to na 
fsck nemelo prilis negativni vliv. Porad to byl cas kolem 11 sekund 
(plus minus setina)

Posledni pokusy byly s optimalizaci podle prumerne velikosti souboru, 
kterou jsem vzal podle vystupu "df". Tedy zabrane misto, deleno poctem 
vyuzitych inodu:

# df -i -t ufs /vol1 | tail -n +2 | awk '{ print $3" / "$6" = "$3/$6 }'
1697619120 / 9648452 = 175.947

Z toho pak vzniklo tohle newfs

newfs -U -b 64k -f 8k -i 96k -g 176k /dev/mirror/gm1p8

Na cas fsck to nema zadny vliv. Predpokladam tedy, ze to bude spis 
ovlivnovat fragmentaci. Je to tak?
V takovem pripade bych asi spis volil vetsi cislo, protoze do vypoctu 
tech 176k se zapocitavaji i inody pro vsechny adresare, kterych je tu 
opravdu hodne, protoze je to struktura v nekolika urovnich, na zpusob:
aa/aab/aabzakaznik/_soubory_uzivatele_aabzakaznik_.jpg
..
zz/zza/zaakaznik/_soubory_uzivatele_aabzakaznik_.mp3

A registrovanych uzivatelu je nekolik set tisic.


K tomu fsck - je mi jasne, ze fsck prazdneho oddilu dela neco uplne 
jineho, nez fsck oddilu, ktery je plny dat, nejaka smazana data atd. ale 
nevim, co presne se tam pak overuje. Zustanou tyto proporce zrychle 
platit i pro zaplneny filesystem? Ze treba misto pul hodiny fsck to 
probehne za 8 minut?

Mirek