OpenZFS a mindennapokra

Az otthon tárolt adatmennyiség növekedése miatt szükségessé válhat saját NAS, melyhez kiváló a ZFS fájlrendszer. – írta: stopperos, 4 éve

ZFS felépítése I.

Bár hajlamos vagyok ZFS fájlrendszerről beszélni folyamatosan, a valóságban a név sokkal többet takar. Két, korábban külön kezelt réteg van egyesítve egy kódbázisba: logikai kötetkezelés (pl. raid) és a fájlrendszer egyben van. Az első réteget normál környezetben a hardveres raid, a dm vagy az lvm2 alkotná. Míg a második rétegnek linuxon az ext[2,3,4], xfs, jfs, reiserfs, f2fs lenne a megfelelője. ZFS-ben csak annyit veszünk észre, hogy a kötetkezeléses feladatokra a zpool, míg fájlrendszeres feladatokra a zfs kezdetű parancsokat használjuk. [link]

A Unixos világban hozzá vagyunk szokva ahhoz, hogy kis programok kis részekért felelnek, és együtt akár bonyolult feladatot is meg tudnak oldani. A ZFS esetén egy nagy kód van, ami sok mindent csinál.

ZFS fájlrendszer otthonául szolgálhat akár egy lemez is. De összefűzhetünk több lemezt raid0, raid1, raidz[1,2,3] (raid5 és raid6) tömbökké, mikor sebességre, mikor adatbiztonságra hajtva. Arra kell csak figyelni, hogy a kialakított struktúrán már nem lehet a későbbiekben változtatni egyszerűen.

A következőkben létrehozok egy raidz1 tömböt 5 azonos méretű merevlemezből. Javaslom mindenkinek, hogy a meghajtókra ne sda és sdb néven hivatkozzon, hanem használja jobban azonosítható nevét:

$ ls /dev/disk/by-id/
ata-HGST_HTS541075A9E680_JA13021H0J6BRK
ata-SAMSUNG_HN-M750MBB_S2R9J9DBA00197
ata-ST34311A_5BF1Y1ZK
ata-ST34311A_5BF1Y1ZK-part1
ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00120759
ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124488
ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124851
wwn-0x5000cca764c75de1
wwn-0x50014ee0569e89cc
wwn-0x50014ee0569e9763
wwn-0x50014ee0abf466d9
wwn-0x50024e92064919a6

Update: egy olvashatóbb verzió, de ehhez a tree csomagot telepíteni kell:
$ tree /dev/disk
/dev/disk
├── by-id
│   ├── ata-HGST_HTS541075A9E680_JA13021H0J6BRK -> ../../sde
│   ├── ata-SAMSUNG_HN-M750MBB_S2R9J9DBA00197 -> ../../sdd
│   ├── ata-ST34311A_5BF1Y1ZK -> ../../sda
│   ├── ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00120759 -> ../../sdc
│ ├── ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124488 -> ../../sdb
│   ├── ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124851 -> ../../sdf
│   ├── wwn-0x50014ee0569e89cc -> ../../sdb
│   ├── wwn-0x5000cca764c75de1 -> ../../sde
│   ├── wwn-0x50014ee0569e9763 -> ../../sdf
│   ├── wwn-0x50014ee0abf466d9 -> ../../sdc
│   └── wwn-0x50024e92064919a6 -> ../../sdd

Akkor hozzuk létre a tömböt pár extra paranccsal[link]:

$ sudo zpool create -o ashift=12 vd-Rocinante raidz1 \
/dev/disk/by-id/ata-SAMSUNG_HN-M750MBB_S2R9J9DBA00197 \
/dev/disk/by-id/ata-HGST_HTS541075A9E680_JA13021H0J6BRK \
/dev/disk/by-id/ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00120759 \
/dev/disk/by-id/ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124488 \
/dev/disk/by-id/ata-WDC_WD7502ABYS-18A6B0_WD-WMAU00124851

Az ashift=12 opció a szektor méretre vonatkozik és a 12 felel meg a 4k-nak. A modern merevlemezek már mind 4k szektormérettel jönnek és 512 byte-nak hazudják magukat. Az írásnál és olvasásnál így gyorsabb lesz a rendszer. Én szeretem sci-fi űrhajókról elnevezni a ZFS fájlrendszereimet, ezért a vd-Rocinante. A lemezek elérési útjai előtt pedig meg kell adni, hogy mi most őket raidz1 (raid5) kötetté akarjuk összefűzni. A legkisebb lemezméret fogja meghatározni, hogy mekkora területet használ fel a többi lemezen.

Az éles szeműek kiszúrhatták, hogy szerverbe szánt merevlemezeket keverek laptop merevlemezekkel. Ez sebességben nem egy jó kombináció és főleg nem raidz1-ben. Ilyenkor az írási sebesség a leglassabb lemezírási sebességével fog megegyezni.

Copy-on-Write és pillanatképek

Mielőtt rátérnénk a ZFS tömbünk és fájlrendszereink adminisztrációjára, előtte pár dolgot meg kell értenünk a fájlrendszerről, hogy tudjuk, hogy az hogyan is tárolja adatainkat. Ha egy fájlt elmentünk, akkor minden a megszokott módon történik (nagyon leegyszerűsítve): az adat blokkok kiírásra kerülnek, és egy meta blokkban az adat blokkokra fog egy-egy mutató mutatni. Ha viszont a fájlt módosítjuk (mondjuk a közepét), akkor az érintett blokk nem íródik felül, hanem egy új blokk jön létre, és az módosul. A meta blokkban lévő mutató pedig már erre az új blokkra fog mutatni. Sőt mivel a meta blokk is módosult, ezért az is átíródik egy új helyre, és ez így megy fel egészen a fa tetejéig. Részletesebben.

Ennek igazából két előnye van: A merevlemezen az adat mindig konzisztens lesz és értelmes (mert a meta blokkok csak az adat blokkok kiírása után íródnak ki) és a fájlrendszer aktuális állapotáról bármikor pillanatkép készíthető (csak meg kell őrizni a korábbi meta blokkokat és adat blokkokat).

Hibaellenőrzés és blokkméret

Minden egyes blokkhoz tartozik egy hash a rá hivatkozó meta blokkban. Minden íráskor a kiírt blokkhoz kiszámolja a fájlrendszer és minden olvasáskor ellenőrzi. Így kerülhetőek el az olvasási hibák vagy például a bitek rothadása (amikor egy idő után a merevlemezen egy bit átfordul véletlenül). Ha egy blokk számolt ellenőrző összege (checksum) és az eltárolt ellenőrző összege eltér, akkor a ZFS hibát dob. Ha elérhető az adott blokk máshonnan (mirror, raid5,...), akkor ad vissza adatot és a hibás blokkot felülírja a helyes adattal. Ha nem ál rendelkezésre a blokkról másolat, akkor nincs javítás.

A jelenleg elérhető checksum algoritmusok a következők: fletcher4, sha256, sha512, skein, edonr. Az első kettő minden operációs rendszeren támogatott, az utóbbi három viszont jóval gyorsabb (edonr a leggyorsabb, de deduplikációra nem használható). Mivel kevés CPU erőforrást igényel, ezért ezt soha ne kapcsoljuk ki, vagy akkor eleve más fájlrendszert használjunk. Számomra ez a ZFS legnagyobb előnye. Azonban azt fontos megjegyezni, hogy ha a boot mappánk is zfs-en van, akkor arra ne állítsunk be új checksum algoritmust, mert az újak nem biztos, hogy támogatottak. Nem fog indulni a rendszerünk. Ez későbbi grub és openzfs verzióknál változhat.

zfs get checksum vd-Rocinante
NAME PROPERTY VALUE SOURCE
vd-Rocinante checksum on default

Itt az on a fletcher4 algoritmusra vonatkozik, az az alap beállítás. De ezen ha szeretnénk változtatni, akkor:

sudo zfs set checksum=edonr vd-Rocinante

zfs get checksum vd-Rocinante
NAME PROPERTY VALUE SOURCE
vd-Rocinante checksum edonr local

Költői megjegyzés: én skein vagy az edonr-t szoktam javasolni, ha már módosítunk rajta. De ez bármikor módosítható és az újonnan lemezre érkező adatokra lesz érvényes.

A blokkméret is állítható a ZFS-nél, pontosabban a maximális blokkméret. Az alapértelmezett 128K. Ha tudjuk, hogy például az adatbázisunk (vagy bittorrent kliensünk) 16 KByte méretben írja a háttértárat, akkor ezt érdemes alacsonyabbra venni. Ez által gyorsul az írás és az olvasás is, mert nem 128 KB-t kell mozgatni. Viszont ha tudjuk, hogy nagyméretű fájlok lesznek a fájlrendszerre bízva, akkor egészen 1 MB méretet is beállíthatunk. De ne felejtsük el, hogy ez a maximális mérete a blokknak, ha egy 640 KB méretű fájlt írunk ki, akkor az csak 640 KB-t fog elfoglalni.

sudo zfs set recordsize=1M vd-Rocinante

zfs get recordsize vd-Rocinante
NAME PROPERTY VALUE SOURCE
vd-Koto recordsize 1M local

Hivatkozások #1, #2

Költői megjegyzés: én 1M-t szoktam javasolni ha nem változó, és nagy fájlok kerülnek kiírásra. Például egy mikroszkóp által készített felvételeket szeretnénk tárolni. De ez is bármikor módosítható és az újonnan lemezre érkező adatokra lesz érvényes.

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények