Vím, že nic nevím. VirtualBox, který umožňuje provozovat virtuální počítače na linux, ale i windows stanicích, vybavených procesory podporující virtualizaci, provozuji více jak 4 roky. Za tu dobu jsem si s tímto prostředím zažil své. Je to nejlepší řešení z těch nejhorších, protože nestojí žádné peníze a funguje poměrně spolehlivě, až dokud nějaký amatérský vývojář neřekne DOST.
Nedávno se mi stala taková věc. Přesunul jsem virtuál na jiný počítač, zkontroloval hash, zda jsou data správně zkopírovaná. Vše sedělo do puntíku. Spustil a provozoval týden. Po týdnu jsem zazálohoval tento virtuál a při spuštění obdržel krásnou hlášku vztahující se k formátu virtuálu VMDK:
inconsistency between grain table and backup grain table.
Většinou se snažím zálohovat častěji, tohle byla vyjímečná situace, protože tam bylo sedm dnů bez zálohy. Byl jsem si po těch letech jistý, že bude všechno v pořádku. Co teď?
Nastalo horečnaté googlování, ze kterého jsem zjistil, že daný problém VirtualBox odstranit údajně neumí. Přitom, jestliže mi daný software řekne, že je ve virtuálu chyba, očekával bych zcela logicky, že mi také nabídne možnosti pro odstranění nebo třeba ignorování této chyby, abych se do virtuálu dostal a mohl dál pracovat. Zjistil jsem, že někdy se oprava provádí tak, že pokud se na začátku vyskytují špatná data (mišmaš), tak se přepíší dané byty ze zdravého virtuálu stejného typu. Tady mě hláška informuje, že se liší záloha od nezálohy, tak fajn, ať se tedy obnoví záloha! Nebo na co to tam je???
V popisu chyby s grainem se praví, že nastává, pokud například vypadne napájení stroje a dojde k přerušení relace. No, u mě za ten týden k žádnému přerušení napájení nedošlo.
Jak jsem zjistil, danou chybu lze opravit pouze softwarem VMware. Ale to je komerční software. Proč by měl být linux uživatel tlačen k tomu, aby svůj problém řešil komerčně?
Další věc, to VMware se musí stáhnout, nainstalovat. Následně se použije příkaz "vmware-diskmanager -R CESTAKVMDK". Údajně se oprava provede.
No, tenkrát jsem to udělal jednoduše. Než ztrácet hodiny času (kopírování, oprava), prostě jsem obnovil starou zálohu. Spustil a zase vše jelo. Tentokrát jsem byl podezřívavý, tak jsem zálohoval častěji. Až jsem opět narazil na stejnou chybu s GRAIN TABLE.
No, to mě naštvalo. Kde je, kudla, chyba? To si už ničím nemohu být jistý???
A tak jsem v zoufalství upgradoval VirtualBox, upgradoval Kernel a restartoval Linux. Ten samý soubor VMDK, na kterém mi VirtualBox hlásil ten zasra..ý grain, jsem spustil. A SVĚTE, DIV SE! Spustil se BEZ ODMLUVY!
Takže máme několik možností.
Možnost a) Amatérský vývojář něco zvrtal a opravu naštěstí vykonal v další verzi VirtualBoxu.
Možnost b) Po čase je téměř každý VMDK soubor pod VirtualBoxem zagrainovaný, ale kontrola na to byla zatím vypnutá, protože nebyla možnost opravy. Jakmile zapli v některé z verzí kontrolu, tak se v diskusích ozývaly stovky uživatelů (procházel jsem ty diskuse), že mají VirtualBoxem neřešitelný problém. A tak ten boreček tu kontrolu zase vypnul.
Možnost c) VirtualBox mě chce překvapit, a tak udělal výjimku a chybu mi nesdělil. Sdělí mi ji zase příště, aby mi trochu zvednul adrenalin.
Od té doby jsem tento virtuál restartoval a zálohoval dvakrát a žádný grain se nekonal. A podotýkám, že jsem opravu NEPROVEDL.
To mi připomíná nedávné šílené chování OpenSuse Tumbleweed, ve kterém padal YAST (obdoba ovládacích panelů ve Widlích) na hubu, a pak jsem po několika dnech upgradoval systém (upgradoval jsem ho i před tím, ale bezúspěšně) a šílená chyba byla pryč.
ZávěremJe to tak. V opensourcovém světě si musíme zvyknout na to, že se chyby dějí. Dále si musíme zvyknout na to, že programují jen ti, kteří na to mají čas, ale nemají zkušenosti, a nebo ti, kteří mají zkušenosti, ale nemají čas. Obojí se projevuje na kvalitě práce, která je horší a v normálně fungujícím komerčním světě bez regulačních zásahů a dotací by zcela jistě při zdravém konkurenčním prostředí neobstála.
Zdroj:
názor a zkušenosti autora