Bygde en programvare-RAID, startet på nytt, og lagringen er borte: settet settes ikke sammen ved oppstart

Du slo sammen diskene, settet kom opp, lagringen dukket opp, du skrev data til den. Alt virket.

Så startet du maskinen på nytt, og lagringen er borte.

Diskene er i orden. Dataene ligger der fortsatt. Det som mangler er noe annet.

Et sett ligger ikke på diskene, det ligger i monteringsanvisningen

Å vise flere disker som én lagring er ingen egenskap som sitter på diskene. Ved hver oppstart må systemet finne de diskene og sette dem sammen igjen.

Det finnes en oppføring som forteller hvordan. Uten den oppføringen blir settet kanskje ikke satt sammen. Og selv om det blir det, kan det komme opp under et annet navn, noe som går ut på det samme: lagringen din peker på det gamle navnet, og der er det ingenting.

Problemet er altså ikke "dataene er tapt", men "veien til dataene ble ikke bygd ved oppstart". Det høres mindre skremmende ut, men i skrekkøyeblikket føles de likt.

Proxmox sitt eget standpunkt

Dette fortjener å sies ærlig: den innebygde og støttede veien på Proxmox er ZFS. Be om diskspeiling under installasjonen, og det er det du får.

Klassisk programvare-RAID virker, men det er ikke veien installasjonsprogrammet setter opp for deg. Det betyr at når du velger den, ligger det på deg å sørge for at stegene for sammensetting ved oppstart ble gjort riktig.

Det finnes likevel tilfeller der det er fornuftig: du har allerede et sett og flytter det, kontrollerens oppsett er ikke det ZFS venter seg, eller maskinens minne er knapt for ZFS. Det er ekte grunner. Å velge uten grunn er å skaffe seg arbeid senere.

Regelen: et sett som ikke har sett en omstart, teller ikke som et sett

Dette er den mest praktiske setningen i artikkelen.

Etter at settet er bygd, start på nytt én gang med vilje, mens ingenting avhenger av det. Kommer lagringen tilbake, kommer den tilbake med samme navn, ser du innholdet?

Det samme skrev vi i artikkelen om varsler i denne wikien: en uprøvd alarm er ikke en mekanisme, den er et håp. For et sett gjelder det samme. Et sett som ikke har overlevd en omstart, er et sett du tror virker.

Navnebyttefellen

Den andre vanlige fellen: settet blir satt sammen, men under et annet navn enn forrige gang.

Lagringsdefinisjonen din peker på det gamle navnet, så lagringen er usynlig igjen. Denne gangen står settet, men ingen ser på det.

Løsningen er å knytte lagringen til identitet i stedet for navn. Navn kan endres, identiteter gjør det ikke.

Hva Atlas gjør

Når Atlas bygger et sett, skriver det også oppstartsoppføringen, og det viser denne advarselen på skjermen: hvis dette steget mislykkes, blir settet kanskje ikke satt sammen ved oppstart, og lagringen blir usynlig.

Advarselen stemte. Men en periode motsa den seg selv.

For å lage oppføringen ble systemets eget verktøy kalt. Det ble målt, og dette kom fram: når det ikke finnes noe sett i det hele tatt, avslutter det verktøyet med kode null og skriver ingenting. Det sier altså "vellykket" og gir deg ingenting.

Følgen: ingenting ble skrevet, men steget ble bokført som vellykket. Nøyaktig det advarselen nettopp hadde beskrevet, skjedde med brukeren, mens skjermen viste at alt var i orden.

Rettingen besto av to deler. Det forventede formatet ble bestemt ved måling i stedet for gjetting, og passer ikke utdataene til det formatet, teller steget som mislykket. Tomme utdata er også et mislykket forsøk. Og for ikke å skrive det samme settet to ganger, sjekkes både enhetsbanen og identiteten.

Den generelle lærdommen

Setningen som betyr noe her, er denne: "kommandoen lyktes" og "arbeidet ble gjort" er ikke det samme.

En sluttkode forteller om verktøyet kjørte. Den forteller ikke om resultatet oppsto. Er hele hensikten med et steg å frembringe en virkning, er det som skal sjekkes ikke verktøyets tilstand, men virkningen selv.

Det finnes to andre artikler av samme familie i denne wikien. I den om foreldreløse disker skilte vi et tomt svar fra det å ikke få svar. I den om navnet på tjeneren lå faren i å sette en rimelig utseende standardverdi i stedet for det ukjente. Dette er den tredje: å sette en sluttkode i stedet for et resultat som aldri ble fastslått.

Alle tre er ansikter av den samme feilen: programmet påstår noe det ikke har bekreftet.