Miroslav Lachman wrote:
Pro GPT zase nelze pouzit gmirror na cely disk, ale jedine na jednotlive
partitions.
To si nemyslim. Mam dojem, ze problem je jen s bootovanim.
Ja si myslim, ze ono by to z toho mozna i nabootovalo, ale ze se spis
porad jeste hadaji ty posledni sektory, kam si gmirror chce ulozit svoje
metadata a gpt zalozni kopii tabulky z prvniho sektoru. Nebo se pletu a
tohle uz je opraveny?
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.
Disky maji 4k sektory
Seagate Enterprise NAS ST4000VN0001:
Bytes per sector (4K physical emulated at 512-byte sectors)
Takze obycejna klasika s emulaci. Tak nic ;-)
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. Zkus:
dd if=/dev/zero of=fs.dat bs=1k oseek=4G count=1
mdconfig -f fs.dat -u 9
gpart create -s BSD md9
Pak uz jen newfs s parametry dle libosti a hned pote muzes zkusit 'time
fsck_ufs /dev/md9'.
Mezi pokusy bys mel vzdy image odpojit (mdconfig -d -u 9), smazat a
vytvorit znovu. To fsck samozrejme trva uplne jinak dlouho nez na
skutecnem disku, ale proporce - a tudiz efekt tuningu jednotlivych
optionu u newfs by mohl byt rozpoznatelny.
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.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
