zvetseni gmirroru a optimalizace newfs

Dan Lukes dan at obluda.cz
Mon Apr 18 15:26:40 CEST 2016


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



More information about the Users-l mailing list