On 18.4.2016 14:47, Miroslav Lachman wrote:
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.
To skutecne neni problem FreeBSD. Ale ani toho firmware.
Primarni i zalozni tabulka GPT se shoduje - a zalozni tabulka je
umistena na spravnem miste *v ramci datove oblasti toho gmirroru*.
Pochopitelne nikoliv v ramci toho fyzickeho disku - ale ono to GPT taky
neni vytvoreno na fyzickem disku, ale na tom gmirroru.
Zkratka receno - nemuzes cekat, ze firmware, ktery gmirror neumi s nim
dokaze pracovat spravne.
Ono to nebyla korektni konfigurace ani v pripade MBR, kde to fungovalo
jen "nahodou", v pripade GPT se proste ta nekorektni konfigurace jen
projevi zretelne.
Posledni pokusy byly s optimalizaci podle prumerne velikosti souboru,
Musel bych se podivat do zdrojaku a na to ted nemam par dnu ani chvilku
casu, ale myslim, ze zadat prumernou velikost souboru znamena jen
ovlivnit logiku, ktera zvoli velikost bloku a pocet inode. Kdyz je
nezadas. Kdyz je zadas neni co ovlivnovat a tak predpokladam, ze ten
udaj neni nakonec pouzity nijak.
K tomu fsck - je mi jasne, ze fsck prazdneho oddilu dela neco uplne
jineho, nez fsck oddilu, ktery je plny dat, nejaka smazana data
UFS nema "smazana data" jako zvlastni kategorii a pojem. Kdyz bloky
souboru uvolnis, tak jsou proste volne. Proto ostatne nemuze existovat
zadne 'undelete' ...
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.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
