Szoftveres RAID készült, az újraindítás után eltűnt a tároló: a tömb nem áll össze induláskor

A lemezek összevonása megtörtént, a tömb elindult, a tároló megjelent, és adat is került rá. Minden működött.

Aztán jött a gép újraindítása, és a tároló eltűnt.

A lemezek rendben vannak. Az adat továbbra is megvan. Ami hiányzik, az valami más.

A tömb nem a lemezeken van, hanem az összeállítási utasításban

Több lemez egyetlen tárolóként való megjelenítése nem a lemezeken ülő tulajdonság. A rendszernek minden induláskor meg kell találnia ezeket a lemezeket, és össze kell raknia őket.

Van egy bejegyzés, amely megmondja, hogyan. E nélkül a bejegyzés nélkül előfordulhat, hogy a tömb nem áll össze. Ha össze is áll, más néven jöhet fel, ami ugyanoda vezet: a tároló a régi névre mutat, ott pedig nincs semmi.

A probléma tehát nem az, hogy "elveszett az adat", hanem az, hogy "az adathoz vezető út nem épült fel induláskor". Ez kevésbé ijesztően hangzik, a pánik pillanatában viszont a kettő egyformának érződik.

A Proxmox saját álláspontja

Ezt őszintén ki kell mondani: a Proxmoxon a beépített és támogatott út a ZFS. A telepítés során kért lemeztükrözés is ezt adja.

A klasszikus szoftveres RAID működik, de nem ezt az utat készíti elő a telepítő. Ez azt jelenti, hogy ennek választása esetén az indításkori összeállítás lépéseinek helyes elvégzése saját felelősség.

Vannak azért esetek, amikor van értelme: már létezik egy tömb, és annak költöztetése zajlik, a vezérlő elrendezése nem az, amit a ZFS elvár, vagy a gép memóriája szűkös a ZFS-hez. Ezek valós indokok. Ilyen indok nélkül választani annyi, mint munkát adni a jövőbeli önmagunknak.

A szabály: az a tömb, amely még nem élt túl újraindítást, nem tömb

Ez a cikk leggyakorlatiasabb mondata.

A tömb megépítése után érdemes szándékosan egyszer újraindítani, amíg semmi nem függ tőle. Visszajön-e a tároló, ugyanazon a néven jön-e vissza, láthatók-e a tartalmai.

Ugyanezt írtuk le a wiki riasztásokról szóló cikkében is: a nem tesztelt riasztás nem mechanizmus, hanem remény. A tömbre ugyanez áll. Az a tömb, amely nem élt túl újraindítást, olyan tömb, amelyről csak hisszük, hogy működik.

A névváltozás csapdája

A második gyakori csapda: a tömb összeáll, de más néven, mint legutóbb.

A tárolódefiníció a régi névre mutat, így a tároló ismét láthatatlan. Ezúttal a tömb fenn van, csak éppen senki nem néz rá.

A megoldás az, hogy a tároló azonosító alapján kapcsolódjon, ne név alapján. A nevek változhatnak, az azonosítók nem.

Mit tesz az Atlas

Amikor az Atlas tömböt épít, az indítási bejegyzést is megírja, és ezt a figyelmeztetést mutatja a képernyőn: ha ez a lépés meghiúsul, a tömb induláskor esetleg nem áll össze, és a tároló láthatatlanná válik.

A figyelmeztetés igaz volt. Egy ideig azonban aláásta önmagát.

A bejegyzés előállításához a rendszer saját eszközét hívta meg. Ezt megmértük, és ez jött ki: ha egyáltalán nincs tömb, az az eszköz nulla kilépési kóddal lép ki, és semmit nem ír ki. Más szóval "sikert" jelent, és semmit nem ad vissza.

Az eredmény: semmi nem íródott ki, a lépés viszont sikeresként került rögzítésre. Pontosan az történt a felhasználóval, amit a figyelmeztetés az imént leírt, miközben a képernyőn minden rendben volt.

A javítás két részből állt. Az elvárt formátum méréssel dőlt el, nem találgatással, és ha a kimenet nem illeszkedik erre a formátumra, a lépés meghiúsultnak számít. Az üres kimenet szintén hiba. Annak elkerülésére pedig, hogy ugyanaz a tömb kétszer íródjon ki, az eszköz elérési útja és az azonosító is ellenőrzésre kerül.

Az általános tanulság

Az itt számító mondat ez: "a parancs sikeres volt" és "a munka elkészült" nem ugyanaz.

A kilépési kód azt mondja meg, hogy az eszköz lefutott-e. Azt nem mondja meg, hogy az eredmény létrejött-e. Ha egy lépés teljes célja egy hatás előidézése, akkor nem az eszköz állapotát kell ellenőrizni, hanem magát a hatást.

Ebből a családból még két cikk van a wikiben. Az árva lemezekről szóló cikkben elkülönítettük az üres választ attól, amikor nem sikerült választ kapni. A szervernévről szóló cikkben az a veszély szerepelt, hogy az ismeretlen helyére hihetőnek látszó alapérték kerül. Ez a harmadik: a kilépési kód kerül egy soha meg nem állapított eredmény helyére.

Mindhárom ugyanannak a hibának az arca: a program olyasmit állít, amit nem ellenőrzött.