Zrdcadlo pouzitim /dev/ar

[Dan Lukes]

On 09/01/11 16:20, Miroslav Lachman:
>> Ale ano - jako fyzicke zarizeni ano. Ale system musi vedet, ze ta
>> zarizeni jsou uz "otevrena" a data na nich jsou "typu RAID" a zadneho
>> jineho.
>>
>> Nemuze tedy na nich vyhledavat filesystemy. Nemuze na nich identifikovat
>> platnou MBR - protoze jakmile bylo jednou rozeznano, ze disk patri do
>> RAIDu, nemuze na nem proste MBR ani filesystem byt.

> Pokud se jedna o gmirror (ataraid nemohu posoudit), tak se to chova
> "spravne" a skutecne na ad4 / ad6 neni videt ani rozdeleni na slices /
> partitions:

> Problem je v okamziku, kdy je kvuli chybe vyrazen z gmirroru - pak je na
> nem videtelne rozdeleni, filesystem atd.

Ja jsem to nepopsal dostatecne dobre - ano, myslel jsem rpesen tohle na 
co narazis. Ten disk (respektive obsah) je obsahem "RAID" dokonce i v 
okamziku, kdy ho system aktualne nepouziva. Dokonce i kdybys ho prenesl 
do pocitace, kde zadny softwarovy RAID vubec neni.

Jestli aktualne je nebo neni "online" v ramci nejakeho konkretniho RAIDu 
proste neni rozhodujici.


> Coz je na jednu stranu fajn, ze
> se clovek muze dostat k datum na disku, ale problem je to v okamziku,
> kdy se pouzivaji treba labely pro mount a po rebootu se tam to zarizeni
> (label) vyskytuje dvakrat.

No prave. Mohlo by se ti snadno stat, ze v okamziku, kdy z RAID/mirror 
vypadne jeden fyzicky disk (kvuli nejake vade) tak pri pristim restartu 
pri trose smuly namountujes (budes-li mountovat via label nebo ufsid) 
nikoliv ten RAID ale ten vypadly disk.

To je samozrejme na hlavu.

Problem by nenastal, kdyby system respektoval, ze data na tom disku jsou 
RAIDova (bez ohledu na to, jestli je disk aktualne "online").

"Dostat se k datum" neni ve skutecnosti az takovy problem. Tak jako umi 
gmirror disk do RAIDu zaradit, jiste neni problem, aby z disku smazal 
svoji signaturu/datovou strukturu. Tim se z disku stane normalni 
(neraidovy disk) a dal uz si k nemu pristupuj jak chces. A protoze 
takovouhle operaci budes delat explicitne, budes o ni vedet - mas tim 
moznost vyresit problematick ekonsekvence jako duplicitni LABELy nebo 
UFSID ...

Vlastne cele je to o tom, aby se to nechovalo "automagicky" a navic blbe.

> Jenze on je to problem tak trochu na urovni "slepice a vejce", jelikoz
> gmirror umoznuje mirrorovat i slices / partitions, takze pri bootu
> vlastne musi byt pristupne "vse" a pak v zavislosti na poradi
> "ochutnavani" jednotlivych provideru a vrstveni nad sebe dochazi k tomu
> odebirani (zneviditelnovani) labelu.


Me to tak neresitelne nepripadalo. Ve skutecnosti se "spravne" poradi 
poznat da. Ano, za urcite situace se dva provideri mohou domnivat, ze 
urcita cast disku je "jejich" - jenze - v takovem pripade se da poznat, 
ktery ma byt uprednostnen (alespon me pripadalo, ze se mi to v kazdem 
pripade, ktery dokazu vymyslet, dari).

Bohuzel, takhle to implementovane neni. Soucasna logika "dostane to 
prvni, ktery si rekne" je pak skutecne zavisla na poradi, tudiz 
potencialne nestabilni a spatne odolna vuci zmenam konfigurace (protoze 
ty mohou prave zmenit poradi).

No a to je ta hlavni chyba celeho GEOMu, podle me.

> Jednou jsem nad tim premyslel pri cteni jedne diskuze v mailinglistu a
> tak nejak mi to pri zachovani soucasne flexibility prislo docela jako
> neresitelny problem. Musel by se zkratka upravit celkovy navrh fungovani
> GEOMu / metadat / vrstveni.

Do nekterych metadat se zasahnout neda - format, treba, MBR nebo 
bsdlabel je historicky dany a jakakoliv zmena je totalne nemozna.

Ale s tim, ze by bylo upravit logiku fungovani GEOMu souhlasim. 
Neodpustim si ovsem zahudrani, ze zadna zmena by nebyla nutna, kdyby 
nekdo premyslel uz pri jeho navrhu - GEOM neni nic, co by vznikalo v 
nejake davne minulosti, je to relativne nova vec. A nejde o nejake 
spatne odhadnutelne problemy u kterych se dalo rict "bohuzel si nikdo 
nevsimnul". Podle me ma GEOm nektere zasadni problemy uz v zakladnim 
navrhu toho, jak to cele ma fungovat.

Nevim, jestli to docela obycejne nesouviselo s:

  --------------------------------
This software was developed for the FreeBSD Project by Poul-Henning Kamp
and NAI Labs, the Security Research Division of Network Associates, Inc.
under DARPA/SPAWAR contract N66001-01-C-8035 (``CBOSS''), as part of the
DARPA CHATS research program.
  --------------------------------

Granty (i komercni ucastnik projektu) maji nejake svoje terminy, kdyby 
se nesplnily, nemusely by z toho prislusne grantove penize byt nebo by 
sef NAI labs mozna nedostal/nedal nekomu nejake odmeny za splneni 
projektu - mozna se to proste muselo naprogramovat az to nebylo dobre 
rozmysleno v navrhu, mozna se to muselo proste nasadit ac to nebylo az 
tak moc doladene a ozkousene - kdo vi. Samozrejme, ze jen spekuluju.

Vem jen, ze dodneska neni mozne jednoduse provadet nektere relativne 
trivialni operace s diskem "normalne" - musi se vypnout nektere ochrany 
(sysctl kern.geom.debugflags) a nasledne restartovat system. To mi 
pripada prijatelne u MS DOSu, ale ponekud nedustojne systemu z tohoto 
stoleti.

Jenze, jak nejsou chyby jen v implementaci, ale uz v samotnem zakladnim 
navrhu, tak je naprava velmi slozita vec - coz je videt na tom, ze po 
nekoliak letech od nasazeni se stale nedari.

To jsem se zas nejak rozcilil ...

Dan