ZFS felépítése II.
Tömörítés és deduplikáció
ZFS-ben lehetőség van a blokkszintű tömörítésre. Ez az operációs rendszer számára láthatatlanul zajlik a háttérben. Jelenleg a következő algoritmusok érhetőek el: lz4, gzip[1-9], lzof, zle, lzjb. Újabb rendszerek esetén a zstd-fast és zstd algoritmusokat is lehet használni. Ebből a legjobb sebességet és tömörítési arányt az lz4 produkálja, amit én javasolnék minden rendszeren használatra. Előnye, hogy ha úgy érzékeli, hogy az éppen kiírt fájl nem tömöríthető, akkor nem is próbálkozik tovább, és a fájl tömörítetlenül kerül a lemezre. Legnagyobb tömörítést a gzip9-cel érhetünk el, hatalmas CPU használat mellett. Akkor is tömöríteni próbál, ha a fájl nem tömöríthető. Míg adatbázisokhoz a legegyszerűbb zle-t javaslom, ami csak a nullákat tömöríti. Újabb rendszerek esetén pedig érdemes a zstd-vel kísérletezni, ami a gzip algoritmushoz hasonló vagy jobb eredményeket produkál, de mégis gyorsabb, különösen olvasáskor.
A jól megválasztott tömörítés előnye, hogy gyorsul az írás és az olvasás, mert a lemezre kevesebb adat kerül kiírásra vagy beolvasásra. Nagyobb blokkmérettel pedig lehet növelni a tömörítés hatékonyságát is.
sudo zfs set compression=lz4 vd-Rocinante
zfs get compressratio,compression vd-Rocinante
NAME PROPERTY VALUE SOURCE
vd-Rocinante compressratio 1.40x -
vd-Rocinante compression lz4 local
A százalék itt a teljes zpool-ra vonatkozik, minden datasetjével.
Költői megjegyzés: én lz4-et szoktam beállítani alapértelmezetten. Az utóbbi időben elkezdtem kísérletezni a zstd-5 és zstd-10 algoritmusokkal olyan helyeken, ahol van lehetőség az adatot tömöríteni (csv jellegű mérési adatfájlok, Matlab változó mentések, ...) De ezt a részt mérni kell, és az lz4 jó kiindulás, mert megmutatja, hogy van-e értelme tömörítésen gondolkodni. Ezen is lehet utólag állítani, és az új kiírt adatokra lesz érvényes.
Érdekes például az openwrt fordítási dataset-em, itt érdemes elgondolkodni a zstd-5-re váltáson, ha nem akasztja meg a fordítást. Míg mondjuk a játszóteres-szemetesdomb nem igazán tömöríthető, így az maradhat lz4-en.
zfs get compressratio,compression vd-Rocinante/openwrt
NAME PROPERTY VALUE SOURCE
vd-Rocinante/openwrt compressratio 1.91x -
vd-Rocinante/openwrt compression lz4 inherited from vd-Rocinante
zfs get compressratio,compression vd-Rocinante/playground
NAME PROPERTY VALUE SOURCE
vd-Rocinante/playground compressratio 1.03x -
vd-Rocinante/playground compression lz4 inherited from vd-Rocinante
Amit viszont nem javasolok, az a deduplikálás. ZFS esetén csak a blokk szintű deduplikálás érhető el. Viszont az ehhez tartozó táblázat memóriaigénye hatalmas, és a tömörítésnél nem ad jobb eredményt. Csak tényleg indokolt esetben szabad használni (sok azonos fájl).
Titkosítás
Ez egy külön írás lesz, mert a kulcskezelést még nem oldottam meg normálisan. Zfs on Linux v0.8-tól elérhető és errefelé van jó leírás.
Gyorsítótár: ARC, L2ARC, ZIL
Mielőtt rátérnék, hogy hogyan is működik a gyorsítótárazás a ZFS fájlrendszerben, előtte átnézném a probléma elméleti hátterét. Ha a háttértárról olvasunk egy blokkot, akkor előnyös lenne, ha a következő alkalommal már nem kellene megvárni, amíg a korábbi újra kiolvasásra kerül, hanem sokkal gyorsabban, memóriából lehetne kiszolgálni az igényt. Azonban egy rendszeren elérhető RAM mennyisége véges erőforrás, így nem tárolható az összes korábban olvasott blokk. Valami alapján el kell dönteni, hogy melyek tarthatóak a memóriában és melyek üríthetőek ki onnan. Alapvetően kétféle megoldás létezik arra, hogy ezt a döntést olcsón meg lehessen hozni. Az első a memóriában tárolt blokkokat utolsó elérési idő szerint rendezi sorba (MRU-LRU) és a lista legvégén lévőt törli. A másik megoldás a memóriában tárolt blokkokat az elérések száma szerint rendezi (MFU-LFU) és a lista végén lévőt, a legkevesebb elérési számmal rendelkezőt törli. Mindkét megoldásnak megvannak az előnyei és hátrányai. Bizonyos feladatok esetén az egyik jobb választás, mint a másik.
A való életben azonban ennél bonyolultabb a helyzet, mint mindig. Hogy mindkét megvalósítás előnyét ki lehessen használni a ZFS fájlrendszer gyorsítótárának egyik fele elérési idő alapján, míg a másik fele elérési frekvencia alapon rendezi a memóriában lévő blokkokat. Nagyjából úgy kell elképzelni, hogy ha egy memóriában lévő blokkra másodszor is írási kérés érkezik, akkor az MRU-LRU táblából átkerül az az MFU-LFU tábla megfelelő sorába. Ez lenne a Replacement Cache működési elve. Még annyi trükk van, hogy egy második táblapáros is van, ahol az egyes táblákból kiesett blokkok címe van eltárolva az adatok nélkül. Ha a későbbiekben egy olyan olvasási kérés érkezne, amely egy olyan blokkot akar elérni, ami ezen utóbbi táblapárosban van, akkor azt a rendszer jegyzi magának. Az eredeti táblapáros belső határát (az időalapú és a frekvencia alapú rész között) pedig a rendszer úgy módosítja, hogy csökkentse a másodlagos táblába kerülő blokkok számát. Innen jön az Adaptive rész, és kész is az első betűszó.
Az L2ARC-ot úgy kell elképzelni, mint a processzornál a L2 gyorsítótár; ami nem fér bele az L1-be, vagy onnan kiszorul, az átkerül egy lassabb gyorsítótárba. Itt is hasonló a helyzet, a második szint tipikusan egy-két csatlakoztatott gyors SSD szokott lenni, ami megnöveli az eredeti ARC méretét, és még több blokk gyorsítótárban tartását teszi lehetővé az olvasási kérések gyorsabb kiszolgálására. További poén és egy nem olyan régi újítás, hogy az ARC és az L2ARC nagyobbik részén a blokkok kitömörítetlenül vannak a memóriában. Ahogy azt korábban megbeszéltük LZ4 tömörítés esetén a kitömörítési művelet nagyon gyors, így ez nem jelent problémát. Ennek az az eredménye, hogy még több blokk tárolható a gyorsítótárban és csak egy kis processzoridőt kell beáldozni. Természetesen ez kikapcsolható funkció.
L2ARC-nak egy gyors SSD-t szokás beállítani, nem kell tükrözni. A mindennapi felhasználás során erre nincs is szükség. Illetve fontos megjegyezni, hogy újraindítás során a cache feltöltése nulláról indul, tehát kell pár óra-nap használat, hogy megteljen. Bármikor hozzáadható és bármikor eltávolítható, csak ne felejtsük le a cache-t hozzáadásnál.
sudo zpool add vd-Rocinante cache /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S21PNXCGA16365B
sudo zpool remove vd-Rocinante /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S21PNXCGA16365B[
A harmadik betűszó a ZIL, ami a szinkron írási kérések gyorsítótára. Ha az alkalmazás vagy szolgáltatás kéri, akkor az írási műveletek szinkron történnek, ezért ennek gyorsításához lehet egy köztes gyorsítótár réteget kialakítani. A végeredmény így az lesz, hogy az írások mindig a ZIL-be fognak kerülni először, majd onnan a fájlrendszer lassabb részére kerülnek kiírásra. A sikeres visszajelzés pedig már a ZIL-be történő írás után fog érkezni.
Hivatkozás #1
Költői megjegyzés: A ZIL a 64K méret alatti szinkron írások gyorsítására van, tipukusan adatbázisokhoz. Az írások nagy része aszinkron, így azt a zfs eleve gyorsítani fogja. Erre nem lesz szükségünk. De ha mégis, akkor tükrözve adjuk hozzá a zpool-hoz.
A cikk még nem ért véget, kérlek, lapozz!
