Podivne chovani gmirror/gpart

[pm-conf at kostax.cz]

> [a] je oznaceni slice v BSD schematu. Takze tady je gmirror a nad nim 
> BSD. To je pomerne raritni konfigurace.

ano, asi trochu netycpa. Asi to vznikalo tak, ze jsem mel opravdu 
jednodiskovou instalaci  a teprve pozdeji jsem delal gmirror. Tohle byla 
cesta nejmensiho odporu. Bavime se tady treba o dobe verzi FreeBSD 6,7,...

Sel jsem podle nejakeho howto, asi to nebyl uplne doporucovany postup, 
uz opravdu nepamatuju.


> BSD sice do posledniho sektoru nezapisuje, ale freebsd-ufs svazek, ktery 
> na nem vytvoris ano. Pokud byl vytvoren v dobe, kdy disk nebyl rizen 
> gmirrorem, prekryva se svazek se sluzebnimi daty gmirroru a nasledne 
> vytvoreni gmirroru poskodilo posledni blok filesystemu. Ale netusim z 
> hlavy co v nem je.

to je mozne. Jen bych upresnil, ze podobne resenych BSD jsem mel mezi 
10-20. Obcas nejaky disk odesel, bez problemu jsem ho menil. Tento 
problem se mi objevil poprve.

>> kern.geom.part.check_integrity=0 v /boot/loader.conf, ktery jsem nekdy 
>> kolem FreeBSD verze 10 musel zacit pridavat, jinak to nenabehlo.

> To je ale taky zvlastni, protoze tohle je potreba jen v pripade GPT. To 
> je test, ktery kontroluje, zda je GPT korektni a ktere GPT nedovoli 
> pouzit, kdyz neni (coz ty musis vypnout, kdyz to korektni nemas).

parametr jsem nekontroloval. Jen vim, ze jsem si s timhle parkrat 
nabehl, tak jsem ho proste zacal pridavat. Klidne je mozne, ze se tyka 
jen GPT a ja to aplikoval zbytecne i na tyhle odlisne stroje.

> Sluzebni data gmirroru mohla byt prepsana. Dokonce i dost davno, jestli 
> nekontrolujes, ze mirror bezi v degradovanem rezimu na jeden disk.

mam v monitoringu, opravdu to do problemu toho disku byl naprosto 
funkcni gmirror. Vypadek disku se projevil po neocekavam vypadku elektriky


> Mluvi  o situaci, kdy uz delsi dobu system bezel na mirroru, ktery ale 
> obsahoval jen prvni disk a druhy nepouzival neb ho nemel za korektni 
> soucast mirroru. Ted prvni zdechnul a zustava disk, ktery obsahuje kdo 
> vi co.

Disk byl opravdu do toho restartu dle gmirroru funkci. Do monitoringu se 
mi kazdych 5 minut zjistuje stav a pocet disku celkem a aktivnich je 2.
Mam tam zaroven nejaky skript, ktery mi v pripade problemu gmirroru 
posle email a to se taky nestalo.

> K poskozeni ale mohlo dojit i primo v souvislosti s opravou, zejmena u 
> prekryvu BSD s gmirrorem. Pri startu systemu se preci pousti fsck a to 
> filesystem opravuje, pricemz na nej zapisuje. Pokud zapsalo do 
> posledniho bloku, muze tam byt z pohledu gmirroru, ktery se ta dat snazi 
> interpretovat, cokoliv. V lepsim pripade by to odmitnul rovnou, jako, 
> sze to nejsou jeho data, v horsim pripade tam najde neco o cem si mysli, 
> ze to jeho data jsou, ale jsou nesmyslna a on se na nich pri pokusu o 
> jejich pouziti zadre. Jo, nemel by, kdyby byl bezchybne napsany, ale 
> zijeme v realnem, nikoliv idealnim, svete.

to nevylucuji. Mam mozna jen smulu, ze se mi tohle na tom mem vetsim 
mnozstvi podobnych stroju tohle nestalo.


> Ano, ale dukladne si zanalyzuj co tam orpavdu mas, zda tam dochazi k 
> prekryvum a jake to muze mit dusleky. Protoze prekryvy nemusi prinest 
> problem hned, ty mohou zpusobovat nahodne problemy podle toho, jak zapis 
> do dat jednoho objektu poskozuje data jineho prektyvajiciho se objektu.

Mam to u zakaznika, takze to neudelam hned. Pozdeji poslu informaci, jak 
to dopadlo.

Petr Macek