Mindenkinek remek hétvégét kívánunk! Ingyenes bemutató órára hívunk! , amelyet Andrej Buranov, a Mail.Ru Group UNIX-rendszerek specialistája tart. Emellett megjelent Jonathan Corbet cikke, az LWN.net executive szerkesztője.
A naplózott fájlrendszerek ígéretet tesznek arra, hogy a rendszergazdák megszabadulnak a lemezmeghibásodások során fellépő problémáktól a rendszer összeomlása esetén. Még a fájlrendszer integritásának ellenőrzése nélkül is. Bár a valóságban persze minden kicsit bonyolultabb. És ahogy a közelmúltban folytatott vita mutatja, talán még zavarosabb, mint sokan gondolnánk, mivel a naplózott fájlrendszerek integritásának biztosítása hatással van a teljesítményre.
A fájlrendszer, mint például az ext3, külön területet használ a lemezen, amelyet naplónak hívnak. A fájlrendszer metaadataiban végzett változtatásokat először a naplóba írják, anélkül hogy a fájlrendszert módosítanák. Miután minden változást rögzítettek a naplóban, hozzáadódik egy „commit blokk”, amely a tranzakció befejezését jelzi. Csak a commit blokk rögzítése után az tranzakció véglegessé válik, és a módosított metaadatok a lemezre kerülnek. Ha a rendszer bármelyik pillanatban összeomlik, a napló információi segítségével biztonságosan befejezhető a munka, elkerülve ezzel a fájlrendszer sérülését, mivel észlelhetően csak a metaadatok egy része frissült.
Egy azonban akadályozza a folyamatot: a fájlrendszer kódjának a commit blokk rögzítése előtt teljes mértékben biztosnak kell lennie abban, hogy a tranzakció minden információja már bekerült a naplóba. Csak az operációk helyes sorrendbe írása nem elegendő — a modern lemezek nagy belső pufferelési lehetőségekkel rendelkeznek, és az operációkat a teljesítmény javítása érdekében átrendezik. Ezért a commit blokk rögzítése előtt egyértelműen jelezni kell az összes naplóadat lemezre történő átvitelét. Ha a commit blokk korábban kerül rögzítésre, a napló megsérülhet. E probléma megoldására barrier-eket használnak. Lényegében a barrier megakadályozza, hogy a barrier után bármely blokk írásra kerüljön, amíg a barrier előtt írt blokkok lemezre nem kerültek. A barrier-ek használatával a fájlrendszerek garantálják a fájl struktúrák konzisztenciáját.
De van még egy probléma: az ext3 és ext4 fájlrendszerek alapértelmezés szerint nem használnak barrier-eket. Van rá lehetőség, de ha az adminisztrátor nem aktiválta őket, akkor ezek a fájlrendszerek barrier nélkül működnek, bár egyes disztribúciókban (például a SUSE) más az alapértelmezett beállítás. Eric Sandeen nemrég úgy döntött, hogy ezt a helyzetet meg kell változtatni, és , amely módosítja az alapértelmezett beállításokat az ext3 és ext4 rendszerek számára. Ekkor kezdődött egy heves vita.
Andrew Morton nagyon részletesen , miért van az alapértelmezett beállítás pont így:
Legutóbb, amikor próbáltuk ezt megváltoztatni, a teljesítmény sok terhelés alatt 30%-kal csökkent, ezért pánikban elvetettem az összes ilyen javítást. Úgy gondolom, hogy ezt nem engedhetjük meg, és nem lassíthatjuk le ennyire az összes gép működését...
Nincs tökéletes megoldás, és hajlok arra, hogy ne ébresszem fel ezt a alvó kutyát, és a disztribúciók fejlesztőire bízzam az alapértelmezett beállításokat.
Így alapértelmezés szerint a barrier-ek ki vannak kapcsolva, mivel ezek komolyan befolyásolják a teljesítményt. Ezen kívül a fájlrendszerek teljesen sikeresen használhatók barrier nélkül. Az ext3 fájlrendszer meghibásodásáról érkezett jelentések meglehetősen ritkák.
De ez nem csupán a szerencsén múlik. Ted Ts’o abban rejlik, hogy az ext3/ext4 napló általában folyamatosan helyezkedik el. Először is, a fájlrendszer meghajtója próbálja folyamatosan létrehozni azt. Másodszor, a napló általában a fájlrendszerrel egyidejűleg keletkezik, amikor könnyen található folyamatos terület. A kontinuitás és a rendezettség nemcsak a teljesítmény, hanem a felcserélés megelőzése szempontjából is hasznos. A commit blokk általában az összes többi adat után kerül elhelyezésre a naplóban, így a lemeznek nincs oka a felcserélésre. A commit blokk természetes módon közvetlenül az összes naplóbejegyzés után íródik a lemezre.
Ennek ellenére senki sem állítja, hogy ez mindig így lesz. A merevlemezek másképp is viselkedhetnek. Ezen kívül a napló egy körkörös puffert képez. Ezért, amikor egy tranzakció a napló végére kerül, a commit blokk egy korábbi blokkban helyezkedhet el, más naplóbejegyzések előtt. Így mindig van esély a meghibásodásra. Valójában Chris Mason erről rendelkezik. Nincs kétség afelől, hogy a barrier nélküli munka kevésbé biztonságos, mint a barrierrel végzett munka.
Ha hajlandóak vagyunk teljesítménycsökkenést elfogadni, akkor aktiválhatjuk a barrier-eket. Természetesen csak abban az esetben, ha a fájlrendszere nem LVM alapú (ahogy néhány disztribúció alapértelmezetten van). Kiderül, hogy a device mapper nem támogatja a barrier-eket. Egyébként jó lenne csökkenteni a teljesítménycsökkenést. Úgy tűnik, hogy ezt meg is lehet tenni.
Az ext3 jelenlegi megvalósítása (amikor a barrier-ek engedélyezve vannak) minden egyes tranzakció során a következő műveletsorozatot hajtja végre:
Az adatok a naplóba íródnak
Barrier végrehajtása
A commit blokk rögzítése
A következő barrier végrehajtása
Később a metaadatokat a lemezre írják
Az ext4 esetében az első barrier (2. lépés) kihagyható, mivel az ext4 fájlrendszer naplóellenőrzéseket támogat.
Ha a napló adatai és a commit blokk átrendeződnek, és a művelet megszakad egy hiba következtében, a napló ellenőrző összeg nem fog egyezni a commit blokkban tárolt összeggel, és a tranzakciót elutasítják.
Chris Mason , ami szerint "általánosan biztonságos lenne" eltávolítani ezt a barrier-t az ext3-ból, kivételt képezve, amikor a napló a végére ér és újra az elején kezd írni.
Egy másik ötlet a teljesítmény növelésére az, hogy lehetőség szerint késleltessük a barrier műveleteket. Ha nincs sürgős szükség az adatok azonnali lemezre írására, akkor több tranzakciót hozhatunk létre a naplóban, és egy barrier-rel írhatjuk rá a lemezre.
Van némi potenciál a javításra a műveletek gondos sorrendjének biztosításával, hogy a barrier-ek (amelyek általában arra a kérésre válaszolnak, hogy "írja le az összes késleltetett műveletet a lemezre") ne kényszerítsenek a blokkok olyan írására, amelyek nem igénylik a sorrendiséget.
Úgy tűnik, itt az idő, hogy átgondoljuk, hogyan tehetjük a barrier-ek költségeit elfogadhatóvá. Ted Ts’o úgy tűnik, :
Szerintem a barrier-eket be kellene építenünk az ext3/4-be, majd arra kellene összpontosítanunk, hogy csökkentsük a költségeket az ext4/jbd2 esetében. Valószínűleg a többségi rendszerek nem olyan körülmények között működnek, mint amilyenekkel Chris a probléma szemléltetésére használt, és a fájlrendszer biztonságának alapértelmezetten prioritást kell adni.
Az utcai józanságom azt mondja, hogy ez a kutya már nem alszik, és valószínűleg egy ideig ugatni fog. Ez néhány szomszédot aggaszthat, de jobb, mint ha megharapna valakit.
Érdekel, hogy ebben az irányban fejlődj? Jelentkezzen ingyenes bemutató órára és vegyen részt az átadásban , amelyet Pavel Vikiryuk tart — MVNO kommunikációs operátor, DevOps mérnök.
Forrás: habr.com
