On 02/02/13 13:50, Miroslav Lachman:
Ale i kdyz vezmes nejdriv dva disky, nad nima vytvoris gmirror a ten budes chtit rozdelit pomoci GPT, tak se dostanes do problemu.
Bud' je tam vada o ktere nevim, nebo nikoliv.
Problemy jsou v tom hned dva. Prvni je ten, ze jednotlive tridy (vrstvy) GEOMu se chovaji tak, jako by jedna o druhe vubec nevedela
Ano, ale to nepotrebuji.
a nejsou schopne poznat "cizi" metadata a v metadatech neni ani ulozena informace o poradi vrstev... takze pri bootu systemu se tezko rozlisuje, v jakem poradi se maji vrstvy na sebe poskladat. Jestli je to mirror disku, nebo oddilu, jestli label, nebo journal patri oddilu na disku, nebo oddilu na mirroru atd.
Ano, to je pravda, to je problem situace, kdy se prekryvaji vrstvy, z nichz jedn auklada metadata napocatek a druha nakonec. Coz neni pripad GPT versus gmirror, ktere obe ukladaji sva data na konec.
Kdyz kouknu do posledniho sektoru, najdu jedna metadata jen jedne vrstvy. Az je zpracuju a ziskam "uroven vys", pak ano, pak v poslednim sektoru teto vrstvy mozna naleznu nejaka dalsi metadata.
A druhy a podstatnejsi problem je to, ze GPT zkratka chce mit metadata na konci fyzickeho disku
Nesouhlasim. Mame GPT na Areca radici, a GPT ma sva metadata ulozena vyhradne uvnitr objektu, na kterem byl nainstalovan. Jsem si jisty, ze o poloze sektoru an fyzickem disku nema poneti.
Pro softwarovy radis plati totez - nakonec - GPT instalujes na nejaky objekt. Vrstvy, jak spravne rikas, o sobe skutecne nevedi a tedy on netusi, ze to neni fyzicky disk. On se proste nainstaluje na ten objekt. Tak je to spravne a v takvoem pripade si nikdo zadna metadata navzajem prepisovat nebude.
Samozrejme, jina vec by byla, pokud GPT donutis aby gmirror "prehledl", "zignoroval" na nainstaloval se na "vrstvu o jednu niz" (a kdo vi, jestli to uz je fyzicky disk). Pak si, samozrejme, kolegujes o radu problemu, jejich pravdepodobnost a zavaznost se odviji od toho, zda se neco do neceho "trefi", kdyz to o sobe navzajem nevi.
a ne na konci mirroru (ktery je o vlastni metadata mensi, nebo muze byt mensi klidne o nekolik GB). Ten problem prameni z toho, ze o gmirroru nevi BIOS / UEFI a nektere pocitace odmitnou nabootovat, pokud na disku nenajdou validni i sekundarni tabulku GPT.
To ale zamenujes pricinu a nasledek. Ano, ja verim, ze BIOS / UEFI neumi nabootovat z GPT partition, ktera je umistena v gmirroru. BIOS / UEFI umi logicky nabootovat jen z tech zarizeni a formatu, ktera zna.
Tak jako nebude schopen nabootovat z disku, ktery je fyzicky zasifrovan (pokud nebude uzpusoben a nepreda mu klic) - coz nikoho neprekvapi, stejne tak ale nebude schopen nabootovat ani z disku, ktery je fyzicky normalni, ale data na nej jsou ukladana ve formatu nejaek softwarove sifrovaci vrstvy (GEOM BDE) - a ani to urcite nikoho neprekvapi, nemelo by ani nikoho prekvapit, ze NENI samozrejme, ze nebude umet nabootovat ani kdyz mezi nim a daty an disku bude nejaka mene zretelne prekazejici vrstva. Napriklad gmirror.
Ano, muze se to nahodou povest - kdyz ty vrstvy budou bud' vedome kooperovat, nebo si nebudou prekazet alespon "nahodou".
Jestlize BIOS / UEFI gmirror jako datovy format nezna, je normalni (a neni to chyba gmirroru ani GEOMu), ze z nej nedokaze nabootovat.
Jo - pokud to nahodou pujde, protoze BIOS / UEFI prehledne, ze tam nejaky gmirror je, tak vyhra, ale pokud to neprehledne, lze jen velmi tezko hovorit o chybe.
V mailinglistech to nekolikrat probirali vyvojari, co tohle maji na triku a docela se nedokazali ani shodnout na tom, jak si spravne vylozit ten standard GPT. Ruzna slovickareni na tema "should", "must", "can". A jestli provider je vzdy ten fyzicky disk, nebo mirror nad nim vytvoreny atd. (jelikoz tomu GPT musi rozumet i neFreeBSD systemy)
Samozrejme. Obecne lze vrut do dreva dostat kladivem, ac kladivo nebylo pro toto pouziti navrzeno. Ale na kladny vysledek se neda obecne spolehnout. Ale rozhodne to neni chyba vrutu.
Omlouvam se, nemam takova prirovnani rad, ale uz takhle to mam strasne dlouhy a tohle je nejrychlejsi byt' kontroverzni zpusob jak poukazat, ze resej kvadraturu kruhu.
Takze vysledek je ten, ze pro GPT a gmirror se doporucuje rozdelit jednotlive disky na oddily pomoci GPT a mirrorovat jednotlive oddily. Ne cele disky.
Logicke a spravne reseni - BIOS najde sve GPT na fyzickem disku, a nic jineho on neumi, a kod, ktery nasledne natahne, ten uz gmirroru uvnitr GPT rozdeleneho disku rozumi. Kazdy pak jasne pracuje s daty, kterym rozumi, funkcnost nestoji na tom, jestli se nejakou vrstvu pred jinou podari schovat tak dobre, aby si ji nevsimla - a nikdo nikomu neprepisuje data (protoze se to schovani povedlo a on si tudiz nevsiml, ze tam jsou).
V tomhle vsem si, podle vseho rozumime. Cemu stale nerozumim je, v cem spociva udajna chyba GEOMu. Debata zacala u prepisovani metadat GPT a GMIRRORu a to pri kokrektni konfiguraci podle me nastat nemuze. Dokonce bez ohledu na to v jakem poradi ty vrstvy pres sebe polozis. Problem nastane teprve kdyz porusis vrstevnaty model a na fyzicky disk soucasne polozis GPT i gmirror. Tak se nelze divit, ze si pripadne prepisuji data, ale, jak uz jsem reklm, to preci neni chyba GTP ani GEOMu, ale jen a jen obsluhy, ktera si tuhle podivnou konfiguraci vynutila.
Dan -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
