Chyba cteni disku

[Jan Jurák]

Ahoj vespolek,

Ctu vas mailing list jiz nejakou dobu a tohle je muj prvni post a diky zacatecnictvi nijak vyrazne informativni post, vlastne chci jen pritakat danove povdechu: Z behem asi dvouleteho pouzivani freebsd me strach z bugu ve filesystemu ci geom vrstvy strasi vic nez vsecky chyby v openssl dohromady. Posledne jsem diky smutnemu pribehu uzivatele SU+J (diky mirku za thread) ustoupil z nasazenil na dulezitem stroji. SU+J je pritom oznaceno jako produkcni, jestli se nepletu.

 Prijde mi, ze vyvojari Freebsd jsou nadprumerne inteligentni lidi, kteri se neboji implementovat slozitou myslenku do Cecka. Cecku vubec nehovim, ale behem nekolika pokusu ve zanechalo dojem jazyka stvoreneho ke generovani chyb s velkym naroky na vyvoj/testing. Nevidim uplne do kuchyne freebsd, ale pro tyhle soucasti systemu to chce stabilni testovaci team, ktery je schopny garantovat nejaky seznam setupu pro kazdy releas.

Mel jsem jeden vypadek pole pod ESX a poskozenych UFS2 (9.2ky releng) bylo mnohem vice nez EXT3 (centos 6.x) a uplne  nejlepe si tenkrat  vedlo NTFS. Bohuzel nebyl cas na zjistovani podrobnosti. Virtualek bylo cca 40.


Honza Jurak
  Original Message  
From: Dan Lukes
Sent: středa, 3. září 2014 11:30
To: FreeBSD mailing list
Reply To: FreeBSD mailing list
Subject: Re: Chyba cteni disku


On 09/03/14 10:42, Vitezslav Novy:
>> Proste vezmes disk, ktere byl nekde pouzivanej a na systemu, kterej v
>> sobe vubec podporu pro mirror zakompilovanou nema. Takze vubec netusis,
>> ze krome partition table tam nekde na konci zustala platna tabulka
>> mirroru. Do doby nez jednoho dne bootnes jiny kernel.
>
> Tim bys ale, pred pouzitim disku na tom systemu bez mirrou, porusil
> aspon jednu drive uvedenou zasadu.
> Bud jsi zacal pouzivat disk s platnyma datama na mirroru bez mirror
> modulu a tudiz na nej nepristupoval pres jeho nejvyssi vrstvu nebo jsi
> uz davno zapomnel, co je to za disk, a pak jsi ho mel pred pouzitim na
> zacatku a na konci vynulovat.

Souhlasim.

Vsechno co se snazim rict je, ze ve me nebudi nadseni diskovy subsystem, 
ve kterem je bezpecnost a integrita mych dat az uzce zavisla na "si 
dobre pamatujes" a "vse probehne bez chyby".

Potencialni chyby, pokud mohou vzniknout relativne snadno a mohou mit 
extremne vazne dopady, me proste znervoznuji - a GEOM je takovym chybam 
priznive naklonen.

> jestli se tomu vubec da nejak vyhnout.

Uvazime-li nekonecnou obecnost GEOMu - metadata ulozna "kdekoliv" a v 
libovolnem formatu, nekdy dokocne spravovana nekym uplne jinym, pak 
dokonale problem patrne vyresit nejde.

Slo by je ale omezit. Napriklad jednou sestavenou topologii filtru 
zafixovat/uzamknul. Predstavuju si to tak, ze nizsi vrstva by nebyla 
sestavit se s zadnou jinou vyssi vrstve, nez s tou "na kterou je uzamcena".

Ano, pri obecnosti GEOMu mozna nektere filtry takove uzamceni nebudou 
mit implementovane. V poradku, i takove jsem ochoten obecne pripustit. 
Vim, ze v uplnosti se mi riziko odstranit nepodari. Ale muzu se 
rozhodnout, jestli takovy filtr v topologii chci, i s riziky, ktera to 
znamena.

Pokud se stane neco tak zasadniho, ze potrebuju retezec nejak prekopat, 
pak si ho rad jako superuzivatel odemknu - pak uz to skutecne bude v 
poloze "jsem buh, o mych pokynech se neopochybuje".

Ale co je dovoleno Jovovi neni dovoleno volovi. GEOM by "bozska 
rozhodnuti" samostatne delat proste nemel. Neni-li schopen sestavit 
topologii tak, jak byla zamcena, at se na to vykasle a pocka na me.

Rozhodne nepotrebuju, aby se mi pri bootovani jen proto, ze se cosi z 
nejakych transientnich pricin nepovedlo, sestavila topologie uplne 
jinak, protoze GEOM je velmi snazivy. A aniz by nekdo neco poznal, 
zacnou se data cmarat po necem, po cem se ale fakt cmarat nemaji, takze 
to jina data znici (a o prave zapisovana data muzu nakonec prijit taky) ...

To me pripada jako dost nestastna vlastnost, jakkoli manifestace 
nasledku nebude nijak casta. A tak jsem nervozni ...


Dan

-- 
FreeBSD mailing list (users-l at freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l