Dan Lukes wrote:
To, ze to kvuli zaokrouhlovani "vetsinou projde" neznamena, ze ten postup neni principialne vadny. Rozdil mezi MBR a GPT je jen v tom, ze v pripade GPT nas zaokrouhlovani nezachrani a bouchne to prakticky vzdycky a hned. Pricinou ale neni vada GEOMu ale chyba obsluhy.
S tim nemuzu tak uplne souhlasit. Vim, na co jsi tim textem snazil poukazat i kdyz to pro nekoho mozna nebylo uplne patrny. Ale i kdyz vezmes nejdriv dva disky, nad nima vytvoris gmirror a ten budes chtit rozdelit pomoci GPT, tak se dostanes do problemu.
Problemy jsou v tom hned dva. Prvni je ten, ze jednotlive tridy (vrstvy) GEOMu se chovaji tak, jako by jedna o druhe vubec nevedela 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.
A druhy a podstatnejsi problem je to, ze GPT zkratka chce mit metadata na konci fyzickeho disku 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. A najit ji tam nemuzou, pokud by byla zapsana o kousek vedle, protoze je na gmirroru, ktery je mensi, nez cely fyzicky disk. Dokonce to v ramci FreeBSD je tak schyzofrenni situace, ze i samotny system pri bootu tuhle chybu ohlasuje (ohlasoval). 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)
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. K tomu se pak vaze to, ze pri bootu po vypadku napajeni, nebo havarii systemu se spusti synchronizace vsech tech jednotlivych mirroru paralelne (a k tomu jeste fsck). Teda tak tomu bylo puvodne a vim, ze se to v mailinglistu resilo, ze je potreba to "hacknout", aby se rozlisilo, jestli jsou jednotlive mirrory nad stejnymi fyzickymi disky a pokud ano, tak aby se nespustila synchronizace soucasne, ale serializovane.
Jestli to tak uz je "opravene" mi momentalne neni znamo. Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
