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

[Dan Lukes]

On 09/10/10 16:54, Miroslav Lachman:
>> 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.

Pak by to ale fungovat melo - musis byt ale ukazneny a na existenci 
nejakeho /dev/da0 opravdu dokonale zapomenout.

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

To jsme se trochu zamotali do pojmu "zivy". Tenhle flag ti dovoli 
zapisovat do objektu, ktery je aktivni v tom smyslu, ze ho prave ted 
nekdo pouziva ("je otevreny"). A je tam proto, ze jakmile mas na te 
partition nejake dalsi nadefinovane podrizene struktury, pak je 
prakticky nemozne zaridit, aby se na ne prislusne GEOMy nepripojily - 
takze se nedokazes k te partition dostat v "nepouzivanem" stavu.

To je, samozrejme, obecne take nebezpecny "override", ale neni to presne 
ono co GEOMu vycitam ja.

Kdybyses dostal k partition v neotevrenem stavu (nebo dokazal presvedcit 
consumery, aby ti tu partition na chvili "pujcily"), ten "override" flag 
bys nastaveny nepotreboval a zapis by ti to dovolilo.

Jenze - ono je to i tak spatne a nemelo by. GLABEL by mel odmitnout 
zapis na disk (alespon v te genericke variante kdy ubira sektor) 
kdykoliv, kdy na te partition uz jsou nadefinovane jakekoliv dalsi 
podobjekty - at jsou aktualne otevrene nebo nikoliv. Protoze nevi kam si 
ty podobjekty co pisi a je mozne, ze jim svoji akci neco prepise.

Pripoustim, ze zjistit zda na partition jsou nebo nejsou nadefinovane 
nadefinovane nejake dalsi (sub-)partition je obecne nemozne, ale 
rekneme, ze by stacilo, kdyby rozeznaval alespon ty, ktere jsou aktualne 
v systemu podporovane (to jest pred zapisem svych dat by nechal 
partition "ochutnat" vsechny ostatni GEOMy a jakmile by se nejaky 
"chytil" tak GLABEL uz musi akci odmitnout).

>> Jenze by meli o ten sektor zmensit prostor - coz take udela.
...
>> Mozna jsme tak prave prisli o obsah jednoho souboru. A system
>> pritom bezi jako by se nechumelilo.

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

To "volne misto na konci" je produktem algoritmu v sysinstalu. Nehledal 
jsem ho, mam dojem, ze to nejak souvis se zaokrouhlovanim na hranice 
stop nebo cylindru.

Mozna se mylim, ale predpokladam, ze pro vhodny pocet sektoru a 
geometrii disku ten zbytek vyjde nulovy. Jo, pri nahodnem poctu sektoru 
na disku je to spise nepravdepodobne. Sveris sva data statisticky platne 
pravde a vire v neznamy neznamy algoritmus ? ;-)

> 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

Hm, to me ani nenapadlo - ale je to dalsi pripad "cerne skladky dat" a 
"lineho ochutnavani". Na rozdil od autora clanku, ja si nemyslim, ze tim 
dablem je mixovani prefixove a postfixove identifikace. Zakladni problem 
je, ze identifikace musi umoznit spolehlive rozeznavani "svoji" 
partition a identifikacni kod musi takovou peclivou identifikaci 
provadet. Pritom je to snadne - at uz mam svoje data na zacatku nebo na 
konci - musim tam mit poznamenano jakou jsem mel delku, kdyz jsem 
vznikal. A jakmile zjistim, ze aktualni ochutnavana partition delku 
nemam - tak ej jasne, ze nejde o partition, ktera tehdy vznikala a tudiz 
o partition ochutnavaneho typu.

Cely jeho problem by nevznikl, kdyby GEOM_PART_GPT neadoptoval jako 
"svoji" partition, ktera jeho nebyla -a to nebyla, protoze to ve 
skutecnosti byla partition patrici GEOM_MIRROR. Pritom GPT ma ve svych 
datech ma pozici zalozni kopie hlavicky a z definice vi, ze tato pozice 
ma byt LBA[-1]. Jakmile zjisti, ze ochutnava partition, ktera je delsi 
(nebo kratsi) tak proste vi, ze tohle neni jeho partition.

Je sice hezke, ze se system rozhodl nam udelat radost, prekonat 
postizeni a stejne nastartoval, jenze tahle prehnana aktivita nam ve 
skutecnosti ohrozila ostatni data na disku. Je to proste nedobre 
udelanej system, to at se na me jeho autor nezlobi.

Jenze to uz se zase jen zbytecne rozciluju. Open Source konovi na zuby 
nehled a navzdory tomuhle jde stale jeste o dost dobry system.

Proste je potreba byt velice opatrny, vedet co a jak funguje a 
nespolehat na to, ze system nas pred dusledky nasich vlastnich ukony 
ochrani ...

Dan