Bestående monteringar: den enda rad som kan hindra en maskin från att starta

Monteringen du gjorde för hand försvinner efter en omstart, och att göra den bestående går via en fil som avgör om maskinen startar. En trasig rad där stoppar inte en tjänst utan maskinen.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox fstab bestående montering
  • proxmox disk försvinner efter omstart
  • proxmox startar inte fstab
  • vad är nofail
  • proxmox nfs montering bestående

Du monterar en disk eller en nätverkslagring för hand och det fungerar. Du startar om maskinen och det är borta.

Lösningen är självklar: lägga till en rad i listan över det som monteras vid start. Och där börjar faran.

Den här filen är inte som de andra

De flesta inställningsfiler på tjänaren hindrar, när de är trasiga, en tjänst från att fungera. Är den här filen trasig kanske maskinen inte startar.

Utfallet är inte "tjänsten ligger nere" utan "systemet föll ner i ett räddningsskal". Och i det läget kan du inte ansluta på distans; det krävs tangentbord och skärm eller en fysisk konsol.

Snedvridningen ingen märker

En trasig nätverksinställning är irriterande: du förlorar fjärråtkomsten. Men maskinen startar ändå.

En trasig monteringsrad kan hindra maskinen från att starta över huvud taget.

Ändå är folk långt försiktigare när de ändrar nätverksfilen. Farans ordning är omvänd mot intuitionen, och det är intuitionen som har fel.

Tre regler

Kontrollera strukturen före skrivning. En rad kräver minst tre fält: källa, mål och filsystemstyp. En rad med saknade fält ställer till det för varje verktyg som läser filen.

Skriv odelbart. En halvfärdig skrivning är i den här filen värre än ingen alls: kvar blir en avhuggen fil, och maskinen försöker starta med den.

Låt inte en frånvarande disk hålla maskinen som gisslan. Använd för nätverkslagring och löstagbara diskar den möjlighet som låter starten fortsätta när monteringen misslyckas. Att en säkerhetskopiedisk inte är inkopplad är inget skäl för att tjänaren inte ska starta.

Kontrollfällan: en kontroll som kraschar är ingen godkänd kontroll

Den mest allmänna läxan i den här artikeln står här, och den gäller inte bara den här filen.

Det finns ett standardverktyg för att kontrollera den här filen. Mätt på en riktig maskin kom detta fram: verktyget kraschar när det ser en rad med färre än tre kolumner. Det sprängs alltså precis när det ser den felformade form det ska fånga.

Att ett kontrollverktyg kraschar betyder inte att kontrollen gick igenom. Rätt svar är inte "inget problem" utan "kunde inte kontrolleras".

Ett förfarande som inte gör den skillnaden godkänner den farligaste filen i dess svagaste stund.

Den andra fällan: varje klagomål är inte ett fel

Samma kontrollverktyg kan säga två olika saker, och att blanda ihop dem skapar ett nytt problem.

Ett formatfel betyder att filen inte går att läsa. Det är verkligen farligt och skrivningen bör återställas.

Ett innehållsligt klagomål är något annat: sådant som "målet onåbart vid start" eller "okänd filsystemstyp". Dessa skadar inte filen och kan vara berättigade. Att lägga till en rad för en enhet som ännu inte är ansluten är vanligt och riktigt; möjligheten som låter starten fortsätta finns just för det.

En kontroll som lägger båda i samma korg avvisar en alldeles ny och fullt giltig rad. Med andra ord: en alltför sträng port gör arbetet omöjligt och driver folk till att stänga av porten.

Vad Atlas gör

I Atlas går varje skrivning till den här filen genom en enda dörr. Varje rad kontrolleras strukturellt före skrivning, skrivningen är odelbar, och efter skrivningen läses filen tillbaka och kontrolleras; uteblir det väntade resultatet återställs det tidigare tillståndet.

Båda fällorna ovan hanteras medvetet. Det yttre kontrollverktyget räknas bara som andrahandssignal: kraschar det blir resultatet inte "rent" utan "kunde inte kontrolleras". Och formatfel och innehållsliga klagomål hanteras var för sig; endast ett formatfel leder till återställning, medan innehållsliga klagomål inte sväljs utan rapporteras till anroparen.

Behovet av den skillnaden hittades också genom mätning: i första versionen ledde båda till återställning, och i det läget avvisades till och med en helt ny och fullt giltig rad.

En ärlig historisk notering: produkten skrev förr till den här filen från åtta olika ställen, och på inget av dem kontrollerades om det skrivna var giltigt; på två av dem skrevs hela filen över odelbart. I samma produkt skrevs nätverksfilen, som inte kan hindra maskinen från att starta, odelbart. Den farligare filen var alltså den mindre skyddade. Det mättes och fördes in bakom en enda dörr.

Källor

Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.

Relaterade artiklar

Hur ser det här ut inne i Atlas?

Gå till produktsidan