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