Byggde en program-RAID, startade om, och lagringen är borta: uppsättningen monteras inte vid start

Du slog ihop diskarna, uppsättningen kom upp, lagringen dök upp, du skrev data till den. Allt fungerade.

Sedan startade du om maskinen och lagringen är borta.

Diskarna är hela. Data finns kvar. Det som saknas är något annat.

En uppsättning ligger inte på diskarna, den ligger i monteringsanvisningen

Att visa flera diskar som en enda lagring är ingen egenskap som sitter på diskarna. Vid varje start måste systemet hitta de diskarna och sätta ihop dem igen.

Det finns en post som talar om hur. Utan den posten kanske uppsättningen inte monteras. Och även om den gör det kan den komma upp under ett annat namn, vilket går på ett ut: din lagring pekar på det gamla namnet och där finns ingenting.

Problemet är alltså inte "data är förlorat", utan "vägen till data byggdes inte vid start". Det låter mindre skrämmande, men i skräckens ögonblick känns de likadana.

Proxmox egen hållning

Detta förtjänar att sägas rakt ut: den inbyggda och stödda vägen på Proxmox är ZFS. Be om diskspegling under installationen och det är vad du får.

Klassisk program-RAID fungerar, men det är inte den väg installationsprogrammet sätter upp åt dig. Vilket betyder att när du väljer den ligger det på dig att se till att stegen för montering vid start blev rätt gjorda.

Det finns ändå fall där det är rimligt: du har redan en uppsättning och migrerar den, ditt styrkorts upplägg är inte vad ZFS väntar sig, eller maskinens minne är knappt för ZFS. Det är riktiga skäl. Att välja utan skäl är att skapa arbete åt sig själv längre fram.

Regeln: en uppsättning som inte sett en omstart räknas inte som en uppsättning

Det här är den mest praktiska meningen i artikeln.

Efter att ha byggt uppsättningen, starta om en gång med flit, medan ingenting hänger på den. Kommer lagringen tillbaka, kommer den tillbaka med samma namn, syns innehållet?

Samma sak skrev vi i artikeln om larm i den här wikin: ett oprövat larm är ingen mekanism, det är ett hopp. För en uppsättning gäller detsamma. En uppsättning som inte överlevt en omstart är en uppsättning du tror fungerar.

Namnbytesfällan

Den andra vanliga fällan: uppsättningen monteras, men under ett annat namn än förra gången.

Din lagringsdefinition pekar på det gamla namnet, så lagringen är osynlig igen. Den här gången står uppsättningen, men ingen tittar på den.

Lösningen är att koppla lagringen efter identitet i stället för efter namn. Namn kan ändras, identiteter gör det inte.

Vad Atlas gör

När Atlas bygger en uppsättning skriver det också startposten, och det visar den här varningen på skärmen: om detta steg misslyckas kanske uppsättningen inte monteras vid start och lagringen blir osynlig.

Varningen stämde. Men under en tid motsade den sig själv.

För att skapa posten anropades systemets eget verktyg. Det mättes, och detta kom fram: när det inte finns någon uppsättning alls avslutas det verktyget med kod noll och skriver ut ingenting. Det säger alltså "lyckades" och räcker dig ingenting.

Följden: ingenting skrevs, men steget bokfördes som lyckat. Precis det varningen nyss hade beskrivit hände användaren, medan skärmen visade att allt var i sin ordning.

Rättningen bestod av två delar. Det förväntade formatet bestämdes genom mätning i stället för gissning, och stämmer utdatan inte med det formatet räknas steget som misslyckat. Tom utdata är också ett misslyckande. Och för att inte skriva samma uppsättning två gånger kontrolleras både enhetssökvägen och identiteten.

Den allmänna lärdomen

Meningen som betyder något här är denna: "kommandot lyckades" och "arbetet blev gjort" är inte samma sak.

En slutkod talar om ifall verktyget kördes. Den talar inte om ifall resultatet uppstod. Om hela syftet med ett steg är att åstadkomma en verkan, är det som ska kontrolleras inte verktygets tillstånd utan verkan själv.

Det finns två andra artiklar av samma familj i den här wikin. I den om föräldralösa diskar skiljde vi ett tomt svar från att inte ha fått svar. I den om serverns namn låg faran i att sätta ett rimligt utseende standardvärde i stället för det okända. Detta är den tredje: att sätta en slutkod i stället för ett resultat som aldrig fastställdes.

Alla tre är ansikten på samma fel: programmet påstår något det inte har verifierat.