Tartós csatolások: az az egyetlen sor, amely megakadályozhatja a gép indulását

A kézzel készített csatolás újraindítás után eltűnik, az állandóvá tétel pedig egy olyan fájlon keresztül vezet, amely eldönti, hogy elindul-e a gép. Egy elrontott sor ott nem szolgáltatást állít meg, hanem gépet.

AtlasPVE ·

A bejegyzés ezekre válaszol

  • proxmox fstab tartós csatolás
  • proxmox lemez eltűnik újraindítás után
  • proxmox nem indul el fstab hiba
  • mi az a nofail
  • proxmox nfs csatolás állandóvá tétele

Egy lemez vagy egy hálózati tároló kézzel csatolva működik. A gép újraindítása után eltűnik.

A megoldás kézenfekvő: egy sor kerül az induláskor csatolandó dolgok listájába. Pontosan itt kezdődik a veszély.

Ez a fájl nem olyan, mint a többi

A szerveren lévő konfigurációs fájlok többsége elrontva egyetlen szolgáltatás működését állítja meg. Ha ez a fájl romlik el, a gép el sem indulhat.

Az eredmény nem az, hogy a szolgáltatás áll, hanem az, hogy a rendszer helyreállítási parancsértelmezőbe esett. Ezen a ponton távolról nincs csatlakozás: billentyűzet és monitor kell hozzá, vagy fizikai konzol.

Az aszimmetria, amelyet senki nem vesz észre

Az elrontott hálózati konfiguráció bosszantó: elvész a távoli hozzáférés. A gép attól még elindul.

Az elrontott csatolási sor viszont teljesen megakadályozhatja a gép indulását.

A hálózati fájl szerkesztésekor mégis sokkal óvatosabbak az emberek. A veszély sorrendje a megérzés fordítottja, és a megérzés téved.

Három szabály

A szerkezet ellenőrzése írás előtt. Egy sorhoz legalább három mező kell: forrás, cél és fájlrendszertípus. Az a sor, amelyből mező hiányzik, minden olyan eszköznek gondot okoz, amely beolvassa a fájlt.

Atomi írás. A félbemaradt írás ebben a fájlban rosszabb, mint az írás teljes elmaradása: csonka fájl marad utána, és a gép ezzel próbál elindulni.

A hiányzó lemez ne tartsa túszként a gépet. Hálózati tárolóknál és cserélhető lemezeknél azt a beállítást érdemes használni, amely sikertelen csatolás esetén is engedi folytatni az indulást. Az, hogy egy mentési lemez nincs bedugva, nem ok arra, hogy a szerver ne induljon el.

Az ellenőrzési csapda: az összeomló ellenőrzés nem sikeres ellenőrzés

A cikk legáltalánosabb tanulsága itt van, és nem csak erre a fájlra vonatkozik.

Van egy szabványos eszköz a fájl ellenőrzésére. Valódi gépen megmérve ez jött ki: az eszköz összeomlik, amikor háromnál kevesebb oszlopból álló sort lát. Vagyis pontosan akkor száll el, amikor azt a hibás alakot látja, amelyet el kellene kapnia.

Az ellenőrző eszköz összeomlása nem azt jelenti, hogy az ellenőrzés sikeres volt. A helyes válasz nem az, hogy nincs gond, hanem az, hogy nem sikerült ellenőrizni.

Az a folyamat, amely ezt a különbséget nem teszi meg, a leggyengébb pillanatában hagyja jóvá a legveszélyesebb fájlt.

A második csapda: nem minden kifogás hiba

Ugyanaz az ellenőrző eszköz kétféle dolgot mondhat, és a kettő összekeverése új problémát szül.

A formátumhiba azt jelenti, hogy a fájl nem olvasható. Ez valóban veszélyes, és az írást vissza kell vonni.

A jelentéstani kifogás más: ilyen az, hogy a cél induláskor nem érhető el, vagy hogy a fájlrendszertípus ismeretlen. Ezek nem rontják el a fájlt, és jogosak is lehetnek. Egy még nem csatlakoztatott eszközhöz tartozó sor felvétele gyakori és helyes lépés, és az indulás folytatását engedő beállítás pontosan ezért létezik.

Az az ellenőrzés, amely a kettőt egy kalapba teszi, elutasít egy vadonatúj, tökéletesen érvényes sort. Más szóval a túl szigorú kapu lehetetlenné teszi a munkát, és a kapu kikapcsolása felé tereli az embereket.

Mit csinál az Atlas

Az Atlasban a fájl minden írása egyetlen ajtón megy át. Minden sor szerkezeti ellenőrzésen esik át írás előtt, az írás atomi, írás után pedig a fájl visszaolvasásra és ellenőrzésre kerül: ha a várt eredmény nem jelenik meg, az előző állapot visszaáll.

A fenti két csapda kezelése tudatos. A külső ellenőrző eszköz csak másodlagos jelzésnek számít: ha összeomlik, az eredmény nem az, hogy tiszta, hanem az, hogy nem sikerült ellenőrizni. A formátumhibák és a jelentéstani kifogások kezelése külön történik: visszavonást csak a formátumhiba okoz, a jelentéstani kifogások pedig nem nyelődnek el, hanem jelentésre kerülnek a hívó felé.

Ennek a megkülönböztetésnek a szükségessége szintén mérésből derült ki: az első változatban mindkettő visszavonást okozott, és ebben az állapotban még a vadonatúj, teljesen érvényes sor is elutasításra került.

Őszinte megjegyzés a történethez: a termék korábban nyolc külön helyről írt ebbe a fájlba, és egyikük sem ellenőrizte, hogy érvényes-e a leírt tartalom, kettő pedig nem atomi módon írta felül az egész fájlt. Ugyanebben a termékben a hálózati fájl, amely nem tudja megakadályozni a gép indulását, atomi módon íródott. A veszélyesebb fájl volt tehát a kevésbé védett. Ez mérésre került, és egyetlen ajtó mögé került.

Források

A Proxmox saját dokumentációja. Angol nyelvű, és ebben a kérdésben az övé az utolsó szó.

Kapcsolódó bejegyzések

Hogyan néz ki ez az Atlason belül?

Tovább a termékoldalra