ATA_STATIC_ID, ufsid

Dan Lukes dan at obluda.cz
Tue Dec 8 11:09:18 CET 2009


Petr Macek napsal/wrote, On 12/08/09 09:02:
>> Identifikaci nezavislou na umisteni ti zajistuje geom_label - ale jen v 
>> pripade, ze kazdemu svazku pridelis unikatni label.

> Koukal jsem na
> http://www.freebsd.org/doc/en/books/handbook/geom-glabel.html
> a obcas bych takovou vec ocenil. Ale nejak nechapu to chovani, ktere je 
> popisovano dole jako "unique file system id, ufsid". /dev/ufsid mam 
> prazdne, v logu vidim (proc je tam removed?):
> 
> GEOM_LABEL: Label for provider ad1s1e is ufsid/44a29a812ac02476.
> GEOM_LABEL: Label for provider ad1s1f is ufsid/44a29a8274ff743f.
> Trying to mount root from ufs:/dev/ad1s1a
> GEOM_LABEL: Label ufsid/44a29a81aea075a2 removed.
> GEOM_LABEL: Label for provider ad1s1a is ufsid/44a29a81aea075a2.

Protoze je ten FS namountovany a geom_label labely pro namountovane UFS 
odstrani.

> Kdyz bych chtel tedy mountovat podle ufsid, musim si je vytahnout z logu 
> a zadat je do fstab?

Napriklad. Nebo pouzit
glabel status
nebo pouzit dumpfs

> Pouzivate nekdo glabel (treba tunefs -L home /dev/da3
> nebo i to ufsis)? Jake s tim mate zkusenosti?

Mam neprilis velkou duvery v stabilitu kodu GEOM, a obzvlaste pak 
GEOM_LABEL.

Pochazi z doby, kdy mi system padal a ukazalo se, ze proto, ze mily GEOM 
nacte sektor z disku a na nactena data se pak odkazuje jako na strokturu 
- aniz by ovsem overil, ze na danem mediu je sektor alespon tak velky, 
aby se do nej struktura vesla. Takze se psalo "za pamet" a samozrejme to 
vadilo. Ano, ja vim, ze chyby se vyskytuji vsude a nakonec se opravi, 
ale u GEOMu, ktery je pomerne klicovou komponentou me to proste dost 
zneklidnilo.

Druha negativni zkusenost pochazi je letosniho jara, kdyz jsem pomoci 
'make release' vyrobil vlastni ISO image, ten vypalil a ono z nej 
nejenze neslo instalovat, ale jakmile byl na uz nainstalovanem systemu 
pritomny geom_label tak system s timto CD v mechanice nenabotoval ani z 
toho uz nainstalovaneho disku. To zas bylo proto, ze se geom_label na 
tom CD v ramci zjistovani labelu shanel po sektoru, ktery na tom CD 
nebyl. Ponechme stranou proc tam sektor nebyl - zustava fakt, ze kvuli 
necitelnemu jednomu sektoru na mediu v zarizeni, ktere se navic ani 
nemelo pouzivat nebyl system schopen vubec nastartovat. Bylo by v 
poradku, kdyby toto medium neslo namountovat (ani v tom pripade by 
nebylo v poradku, kdyby pokus o namountovani zlikvidoval cely system). 
Neni ale v poradku, ze system zlikviduje a navic i nenamountovane..

Takze - kdyz GEOM_LABEL funguje, je to uzitecny mechanismus. Otazka je, 
jestli prinosy vyvazi to riziko, ze z nejakeho obskurdniho duvodu 
fungovat nebude ...

A stejne musis davat bacha kdyz menis diskovou konfiguraci - zejmena - 
kdyz pripojujes dalsi disk. Kdyby tam byly take labely a nahodou se 
shodovaly s temi na jiz existujcim disku (nemluvim o mene pravdepodobne 
moznosti, ze pripojovany disk kdyz davni vznikl jako klon stavajiciho a 
ma tudiz i stejen ufsid) tak se snadno stane, ze se namoutnuje neco 
jineho nez clovek predpoklada a nasledne si nejaka data znicis. To uz ja 
radsi at to vubec nenabehne a donuti me to konfiguracni soubory prepsat. 
Proste - kdyz se meni HW konfigurac epocitace, je to treba prislusne 
zohlednit i v konfiguraci softwarove. Automagicke pomucky muzou 
desetkrat pomoct a jednou uskodit tak, ze to za veskerou pomoc nestoji. 
Konfiguraci HW nemenim tak casto, abych si SW konfigurace nemohl prepsat.

Toz u me je to tak ...

Urcite se tu ale najde rada lidi, kteri GEOM_LABEL pouzivaji k veskere 
spokojenosti.


						Dan



More information about the Users-l mailing list