gpart [was: ZFS root, boot selhal po update z 8.0 -> 8.1]

[Miroslav Lachman]

Dan Lukes wrote:
> On 09/09/10 18:33, Miroslav Lachman:
>> Zkratka kdykoliv jsem pouzil glabel, skoncil jsem s hlaskou:
>>
>> da0: the secondary GPT table is corrupt or invalid.
>>
>> Tak jsem se na ten glabel vykaslal...
>
> Je to uz nekolik let, co jsem do kodu GLABEL koukal - a pokud si to
> vybavuju spatne, tak on je GLABEL docela mrska. Nektere datove
> struktury, ktere pojmenovava, proste originalne zadny prostor pro text
> jmena nemaji. A tak si je strka "nakonec".
>
> Je to ale tak trochu "divoka skladka". Napad "davat si data nakonec"
> nema jen GLABEL. I GPT si dava data (spis druhou kopii) nakonec. A taky
> do LBA[-1]. A nejsou sami - taky softwarove raidy maji tendenci psat si
> data nakonec.

Je to porad tak, ze se metadata zapisuji nakonec a tohle je prave ten 
problem, ze glabel a gpt si to ukladaji do stejne oblasti. Coz je podle 
me bug. Metadata na konec providera uklada kazdy GEOM modul, ktery si 
neco musi ulozit, ale zaroven by pak mel vzhledem k dalsim GEOM modulum 
exportovat mensi velikost toho "zarizeni", takze dalsi metadata by se 
mela zapsat o sektor drive atd. A vetsinou to tak i funguje, ale zrovna 
v tomhle pripade dochazi k nejake kolizi a jelikoz ja si to ze zdrojaku 
neprectu, tak nevim, jestli je na vine glabel, nebo gpart a jestli 
skutecne dojde k prepsani tech metadat, nebo dojde k chybnemu cteni 
metadat (zacne se cist jinde, nez na uplnem konci?)

Az na tenhle problem jinak glabel pouzivam na par mistech k plne 
spokojenosti. V tomhle pripade jsem ho chtel pouzit na to, abych si 
oznacil cele zarizeni da0. Jelikoz se jedna o iSCSI a muze mit libovolne 
cislo v zavislosti na tom, kdy se pripoji, chtel jsem pouzit "jmeno 
zarizeni" udelane glabelem. No nevyslo to...

Mirek