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