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

[Miroslav Lachman]

Dan Lukes wrote:

[...]

>> Metadata na konec providera uklada kazdy GEOM modul, ktery si
>> neco musi ulozit
>
> Jen pro poradek - zdaleka ne kazdy. Takovy geom_part_mbr si nic na konec
> neuklada. A dokonce i ten, ktery ani, tak ne vzdy. Coz je pripad zrovan
> napriklad glabel
> U "znamych typu partition", ktere uz samy o sobe nejaky label maji to
> glabel uklada tam.

Ja tim myslel ty moduly, jako gmirror, glabel, gjournal, graid3, gstripe 
a tak dale... takze ano, nejsou to vsechny GEOM moduly :)

>  > 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.

[...]

> Na vine je glabel - jenze - neni to bug, ale feature. Tedy - ona to
> chyba je - ale chyba v prvotni myslence, nikoliv v jeji implementaci..
>
> Uvedom si, co glabel ma delat - on ma pracovat s textovym oznacenim
> nejaek partition. Kdyby (logicky a bezpecne) delal to, co popisujes ty,
> byl by vysledek jeho cinnosti neco uplne jineho.
>
> Konkretne:
>
> da0 zadne jmeno nema. Takze zavolame glabel, ktery si z da0 ukousne
> posledni sektor, do ktereho da jmeno a soucasne vytvori pododdil o
> sektor mensi. Tim jsme ziskali:
>
> da0, ktery je stale bezejmenny
>
> da0.withlabel - ktery ma jmeno. V nem bys pri[padne mohl delat dalsi
> kouzla (jako rozdelit na slice a podobne). Vznikala by tak jmena jako
> "da0.withlabels1a" a dalsi podobna. Ale da0 - to by bylo stale
> nepojmenovane ...

Ono to takhle ale v podstate je! Jenom misto /dev/da0.mujlabel se 
vytvori /dev/label/mujlabel. A tady bych klidne snesl to, ze bude o 1 
sektor mensi, bude se k nemu vyhradne pristupovat pres label a budu s 
nim pak pracovat klidne pomoci gpart / fdisk atd.

> "Vsezahrnujici" zamereni glabel, ktere si jako cil vytycilo "pojmenujeme
> i to, co s zadnym jmenem proste nepocitalo" je proste spatne zadani - a
> nelze ho implementovat ciste.
>
> glabel mel byt "centralnim mistem pro spravu jmen" - ale mel by s
> eomezit na spravu jmen tech partition, ktere pojem "jmena" maji a
> nepokouset se pojmenovat i objekty, ktere k tomu nejsou uzpusobeny bud'
> bubec, nebo, pripadne, koncept jmena sice maji, ale nikoliv jmena
> uzivatelsky volne volitelneho.
>
> glabelu budiz utechou, ze neni jedinny, kdo ma "maslo na hlave".

No z tohoto pohledu nezbyva nic jineho, nez s tebou souhlasit.

> Trochu podobna instance stejne chyby v uvaze se vaze k gmirroru. Je
> celkem bezne, i kdyz zcela nespravne, ze lidi delaji "mirror" z jiz
> zivych disku. Proste maji disk s funkcnim filesystemem, tak vezmou druhy
> disk a udelaji "mirror". je prakvapive, ze jim to system dovoli

Tady bych si dovolil trochu nesouhlasit, on jim to v podstate nedovoli, 
dokud si uzivatele nepovoli zapis metadat na aktivni disk pomoci
sysctl kern.geom.debugflags=16

  a nutne
> se vnucuje otazka - kam si napsali sva data. No jasne - napsali si je do
> posledniho sektoru. To je v poradku. Jenze by meli o ten sektor zmensit
> prostor - coz take udela. Hacek je, ze UFS (pokdu ej tam UFS) najednou
> sidli v prostoru o sektor mensim. Mozna jsme prave prisli o jeden sektor
> a protoze prostor se spravuje po alokacnich blocich, tak o cely alokacni
> blok. Mozna jsme tak prave prisli o obsah jednoho souboru. A system
> pritom bezi jako by se nechumelilo.

A i tady k tomu mam poznamku - tohle plati v pripade, ze nekdo mirroruje 
samotne oddily (slices / partitions), ale pri pouziti celeho disku (coz 
delam ja) je situace trosku jina. Na konci kazdeho disku, ktery jsem kdy 
rozdeloval sysinstallem / fdiskem je nekolik MB neobsazeneho mista a 
tudiz zapsany 1 sektor metadat nema zadny vliv na existujici oddily a 
jejich filesystem. V tomhle poslednim sektoru proste zadna informace 
(natoz soubor) nelezi.

Realne informace z beziciho serveru:
400088457216 velikost ad4
400088457216 velikost ad6
400088456704 velikost gm0 (gmirror slozeny z ad4 + ad6)
400085844480 velikost, kterou pouzije fdisk pri rozdeleni na slices

  Jedine v pripade, ze jsme takto
> zmirorovali GPT disk trosicku nadava - tim zkracenim o sektor jsme ho
> pripravili o zalozni kopii GPT a o tom se on smutne zmini - ale stejne
> bezi. Pritom by ruzne geomy v ramci "ochutnavani" partition meli
> zjistit, jestli to je regulerni partition, nebo jen nahodne zabloudily
> sektor, ktery nahodou vypada jako by partition definoval. Test na to,
> zda udavana delka partition je vubec k dispozici je to minimum, ktere by
> se melo udelat. Vetsina modulu ale nic takoveho nedela a klidne se
> rozjede i kdyz vi (mohla a mela by vedet) ze na svem konci ma par
> virtualnich sektoru, ktere ve skutecnosti neexistuji.

V tomhle samozrejme souhlasim, je to takove "ochutnavani na slepo"

> No, to jsem se trosku rozcilil. Proste - na to, ze geom je kriticka cast
> systemu je docela zparchantely. Neco jsou napravitelne chyby
> implementacni, neco jsou bohuzel, tezko odstranitelne chyby v samotnem
> navrhu ...

Rozcileni plne chapu, radeji jsem k tomu iSCSI ani nepopisoval, co se 
stane v pripade, ze se do toho zamicha jeste gjournal, ktery ma journal 
na lokalnim disku a data na tom iSCSI disku... gjournal totiz pri bootu 
najde journal na lokalnim pritomnem disku a snazi se ho "nastartovat", 
coz selze, protoze tu jeste neni da0 z iSCSI... porad dokola ochutnava a 
ochutnava a ten gjournal tam nejde ani zastavit, aby se dal spustit az 
pri pripojeni da0... no tehdy jsem si s tim hodne lamal hlavu a nakonec 
jsem z toho vseho musel vynechat jak glabel, tak gjournal.

>> 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...
>
> Tohle je skutecne treba vyresit. Ale glabel v soucasne podobe dobre
> reseni neni. Je potreba prestat cpat jmena kde nativne nejsou a neni je
> kam ulozit a zacit pouzivat ta oznaceni, ktera k dispozici jsou. Fyzicke
> disky maji napriklad seriove cislo.

Myslim, ze asi pred rokem se Ivan Voras pokousel prosadit automaticke 
vytvareni uuid pro disky v /dev, ale z nejakeho duvodu se to nelibilo 
PJD.. uz ani nevim, jak to pak dopadlo. Mam pocit, ze zarizeni je porad 
dostupne pouze jako /dev/da0 a nic jineho... coz je pro to iSCSI porad 
ne uplne dobre.

> PCI zarizeni se zas daji
> identifikovat polohou ve sbernici. Ano - prisli bychom o vlastnost "muzu
> to rozkopat na soucastky, nahodne slozit a ono to stejne bdue fungovat".
> Kterou stejne nemame, protoze to nefunguje spolehlive. U zasahu do
> hadrwaru by se proste obcas muselo prekonfigurovat i neco softwaroveho.
> No boze - zasahy do hardware snad nedela zadny "pojidac kolacu" a my
> jsme profesionalni spravci.
>
> Zato v soucasnem stavu to poradne nefunguje vubec nikomu ...

Nezbyva nez pridat aktualni problem z freebsd-geom:
it's a race between gmirror and UFS labels
http://lists.freebsd.org/pipermail/freebsd-geom/2010-September/004381.html

Mirek