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
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
