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ó.