Hasznos, ha a rendszerünkben legalább 1 GB memória található, de inkább 2 vagy több az ajánlott. Az itt szereplő példákban ehelyett azonban mindenhol csupán 1 GB-ot feltételezünk.

Néhányaknak sikerült 1 GB-nál kevesebb központi memóriával is használni ezt az állományrendszert, azonban ilyenkor nagyon könnyen előfordulhat, hogy komolyabb terhelés esetén a FreeBSD a memória elfogyása miatt egyszerűen összeomlik.

A rendszermag konfigurációs állományából javasolt eltávolítani az összes nem használt meghajtót és funkciót. A legtöbb meghajtó egyébként is elérhető modul formájában, és a /boot/loader.conf állományon keresztül minden gond nélkül betölthetőek.

Az i386TM architektúránál szükségünk lesz az alábbi konfigurációs beállítás megadására, majd a rendszermag újrafordítására, végül a rendszer újraindítására:

options 	KVA_PAGES=512

Ezzel az opcióval a rendszermag címterét növeljük meg, aminek eredményeképpen a vm.kvm_size változót immáron az eredetileg 1 GB-os (PAE használata esetén pedig 2 GB-os) határ felé tudjuk állítani. Az itt megadandó értéket úgy tudjuk meghatározni, ha a beállítani kívánt méret MB-okban számolt értékét elosztjuk néggyel. A példában tehát az 512 egy 2 GB nagyságú címteret ad meg.

A kmem címterét az összes FreeBSD által ismert architektúra esetében érdemes megnövelnünk. A teszteléshez használt rendszeren 1 GB fizikai memória állt rendelkezésre, itt a /boot/loader.conf állományban a következő értékek megadásával minden remekül működött:

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

A ZFS finomhangolásával kapcsolatos további javasolatokat a http://wiki.freebsd.org/ZFSTuningGuide címen olvashatunk.

A zpool kiadásával egyetlen lemezen is létre tudunk hozni egy egyszerű, nem redundáns ZFS partíciót:

# zpool create minta /dev/da0

Az új közös tárterület a df parancs felhasználásával rögtön láthatóvá válik:

# df
Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/ad0s1a   2026030  235230  1628718    13%    /
devfs               1       1        0   100%    /dev
/dev/ad0s1d  54098308 1032846 48737598     2%    /usr
minta        17547136       0 17547136     0%    /minta

A parancs kimenetében tisztán láthatjuk, hogy a minta nevű tároló nem csak egyszerűen elkészült, hanem egyúttal csatolódott. Innentől már a többi állományrendszerhez hasonlóan tetszőlegesen elérhető, az alábbi példához hasonlóan állományok hozhatóak rajta létre vagy listázható a tartalma:

# cd /minta
# ls
# touch proba
# ls -al
total 4
drwxr-xr-x   2 root  wheel    3 Aug 29 23:15 .
drwxr-xr-x  21 root  wheel  512 Aug 29 23:12 ..
-rw-r--r--   1 root  wheel    0 Aug 29 23:15 proba

Sajnos azonban ez a tároló még ki sem használja a ZFS által felkínált lehetőségeket. Ezért most hozzunk létre egy állományrendszert ezen a tárolón belül és engedélyezzük rajta a tömörítést:

# zfs create minta/tomoritett
# zfs set compression=gzip minta/tomoritett

A minta/tomoritett most már egy tömörített Z állományrendszer. Próbáljuk ki mit tud, és másoljunk néhány nagyobb méretű állományt a /minta/tomoritett könyvtárba.

Ezután a tömörítés akár ki is kapcsolható:

# zfs set compression=off minta/tomoritett

Az állományrendszer leválasztásához adjuk ki a lenti parancsot, majd ellenőrizzük az eredményét a df használatával:

# zfs umount minta/tomoritett
# df
Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/ad0s1a   2026030  235232  1628716    13%    /
devfs               1       1        0   100%    /dev
/dev/ad0s1d  54098308 1032864 48737580     2%    /usr
minta        17547008       0 17547008     0%    /minta

Tegyük ismét elérhetővé és csatlakoztassuk újra az állományrendszert, majd nézzük meg az eredményt a df paranccsal:

# zfs mount minta/tomoritett
# df
Filesystem         1K-blocks    Used    Avail Capacity  Mounted on
/dev/ad0s1a          2026030  235234  1628714    13%    /
devfs                      1       1        0   100%    /dev
/dev/ad0s1d         54098308 1032864 48737580     2%    /usr
minta               17547008       0 17547008     0%    /minta
minta/tomoritett    17547008       0 17547008     0%    /minta/tomoritett

A közös terület és az állományrendszer mellesleg a mount parancs kimenetéből is megfigyelhető:

# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1d on /usr (ufs, local, soft-updates)
minta on /minta (zfs, local)
minta/tomoritett on /minta/tomoritett (zfs, local)

Látható, hogy a létrehozásuk után a Z állományrendszerek teljesen hétköznapi módon viselkednek, de természetesen további lehetőségek is elérhetőek hozzájuk. A következő példában adat néven készítünk egy új állományrendszert. Mivel ide majd nagyon fontos állományokat akarunk elhelyezni, állítsuk be, hogy minden adatblokkból két példány legyen:

# zfs create minta/adat
# zfs set copies=2 minta/adat

A df újbóli kiadásával most már látható is ez az állományrendszer és annak tárfoglalása:

# df
Filesystem         1K-blocks    Used    Avail Capacity  Mounted on
/dev/ad0s1a          2026030  235234  1628714    13%    /
devfs                      1       1        0   100%    /dev
/dev/ad0s1d         54098308 1032864 48737580     2%    /usr
minta               17547008       0 17547008     0%    /minta
minta/tomoritett    17547008       0 17547008     0%    /minta/tomoritett
minta/adat          17547008       0 17547008     0%    /minta/adat

Vegyük észre, hogy a közös területen levő állományrendszerek mindegyikén ugyanannyi szabad terület van. A df segítségével a későbbiekben remekül megfigyelhető lesz, hogy az egyes állományrendszerek mindig csak annyi területet foglalnak el a közös területből, amennyire abban a pillanatban ténylegesen szükségünk van. A Z állományrendszerek esetén megszűnik a partíciók és kötetek fogalma, és több állományrendszer tárolódik egyazon közös területen. Ha már nem akarjuk használni, egyszerűen csak töröljük le az állományrendszereket és ezt a közös tárolót:

# zfs destroy minta/tomoritett
# zfs destroy minta/adat
# zpool destroy minta

Nyilván tapasztalhattunk már, hogy a lemezeink olykor menthetetlenül meghibásodnak. Amikor egy lemezes meghajtó tönkremegy, a rajta tárolt adatok általában elvesznek. Az ilyen jellegű kellemetlenségek elkerülésének egyik módja az ún. RAID-tömbök építése. A következő szakaszban bemutatjuk, hogy a Z állományrendszerek esetén hogyan tudunk ilyen tömböket készíteni.

Korábban már utaltunk rá, hogy ebben a szakaszban három SCSI-lemez, vagyis a da0, da1 és da2 eszközök használatát feltételezzük (vagy természetesen ad0 és így tovább, ha IDE-lemezeket használunk). Egy RAID-Z formátumú közös tároló készítéséhez a következő parancsot kell kiadni:

# zpool create tarolo raidz da0 da1 da2

Ennek hatására tehát keletkezik egy tarolo nevű Z-tároló. Ez a korábbiakhoz hasonló módon ellenőrizhető is a mount(8) és df(1) parancsokon keresztül. Természetesen az iménti listába további lemezeszközök tetszőlegesen felvehetőek. Most hozzunk létre ezen a közös területen egy felhasznalok nevű állományrendszert, ahová majd a felhasználók adatait fogjuk tenni:

# zfs create tarolo/felhasznalok

Miután ezzel megvagyunk, az imént létrehozott állományrendszerre nyugodtan beállíthatunk tömörítést és biztonsági másolatokat. Ebben az alábbi parancsok lesznek a segítségünkre:

# zfs set copies=2 tarolo/felhasznalok
# zfs set compression=gzip tarolo/felhasznalok

Ezt követően költöztessük át a felhasználókat, vagyis másoljuk át az adataikat ide és hozzuk létre a megfelelő szimbolikus linkeket:

# cp -rp /home/* /tarolo/felhasznalok
# rm -rf /home /usr/home
# ln -s /tarolo/felhasznalok /home
# ln -s /tarolo/felhasznalok /usr/home

A felhasználók adatai immáron a frissen létrehozott /tarolo/felhasznalok állományrendszeren tárolódnak. Próbáljuk ki, hozzunk létre egy új felhasználót és jelentkezzünk be vele.

Készítsünk most egy pillanatképet is, amelyet aztán később szükség esetén vissza tudunk állítani:

# zfs snapshot tarolo/felhasznalok@08-08-30

A snapshot csak valós állományrendszerekkel működik, könyvtárakra vagy állományokra nem. A nevében a @ karakter választja el egymástól a hozzá tartozó címkét az állományrendszer vagy kötet nevétől. Ha netalán a felhasználói könyvtárak valamiért megsérültek volna, a következő paranccsal állíthatóak vissza:

# zfs rollback tarolo/felhasznalok@08-08-30

Az adott időpontban aktív pillanatképeket az adott állományrendszer .zfs/snapshot könyvtárában találhatjuk meg. Például az előbb készített pillanatkép az alábbi paranccsal nézhető meg:

# ls /tarolo/felhasznalok/.zfs/snapshot

Ha ebből elindulunk, akkor pillanatok alatt írható egy olyan szkript, amely a felhasználók adatairól havonta készít egy pillanatképet. Ilyenkor azonban fontos számításba vennünk, hogy az idővel felgyülemlő pillanatképek rengeteg helyet el tudnak foglalni. A korábbi pillanatkép így távolítható el:

# zfs destroy tarolo/felhasznalok@08-08-30

Miután alaposan kipróbáltuk a /tarolo/felhasznalok néven létrehozott állományrendszerünket, állítsuk be véglegesen ez eddigi /home állományrendszer helyére:

# zfs set mountpoint=/home tarolo/felhasznalok

Ekkor a df és mount parancsok használatával meggyőződhetünk róla, hogy ezt az állományrendszert innentől már valóban a /home könyvtárnak tekintjük:

# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1d on /usr (ufs, local, soft-updates)
tarolo on /tarolo (zfs, local)
tarolo/felhasznalok on /home (zfs, local)
# df
Filesystem          1K-blocks    Used    Avail Capacity  Mounted on
/dev/ad0s1a           2026030  235240  1628708    13%    /
devfs                       1       1        0   100%    /dev
/dev/ad0s1d          54098308 1032826 48737618     2%    /usr
tarolo               26320512       0 26320512     0%    /tarolo
tarolo/felhasznalok  26320512       0 26320512     0%    /home

Ezzel lényegében befejeztük a RAID-Z tömb konfigurációját. Az állományrendszerek állapotára vonatkozóan a periodic(8) alkalmazásával akár naponta kérhetünk ellenőrzést:

# echo 'daily_status_zfs_enable="YES"' >> /etc/periodic.conf

Minden szoftveres RAID implementáció kínál valamilyen megoldást az állapotának ellenőrzésére, ez alól tulajdonképpen a ZFS sem kivétel. A RAID-Z eszközök állapota a következő paranccsal kérdezhető le:

# zpool status -x

Ezt az üzenetet láthatjuk, amikor minden tároló kifogástalanul működik és semmilyen probléma sincs:

all pools are healthy

Ha viszont valamilyen gond lenne valamelyik lemezzel, például leállt, akkor az előbbi parancs eredménye ehhez lesz hasonló:

  pool: tarolo
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
 scrub: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	tarolo      DEGRADED     0     0     0
	  raidz1    DEGRADED     0     0     0
	    da0     ONLINE       0     0     0
	    da1     OFFLINE      0     0     0
	    da2     ONLINE       0     0     0

errors: No known data errors

A válasz szerint az eszközt az adminisztrátor állította le. Ez ennél a példánál valóban igaz. Lemezeket a következő módon lehet leállítani:

# zpool offline tarolo da1

Így miután leállítottuk a rendszert, a da1 eszköz cserélhető. A rendszer soron következő indításakor ezzel a paranccsal tudjuk jelezni logikailag is a lemez cseréjét:

# zpool replace tarolo da1

Nézzük meg újra a tömb állapotát, de ezúttal a -x kapcsoló megadása nélkül, mivel csak így fogjuk látni:

# zpool status tarolo
 pool: tarolo
 state: ONLINE
 scrub: resilver completed with 0 errors on Sat Aug 30 19:44:11 2008
config:

	NAME        STATE     READ WRITE CKSUM
	tarolo      ONLINE       0     0     0
	  raidz1    ONLINE       0     0     0
	    da0     ONLINE       0     0     0
	    da1     ONLINE       0     0     0
	    da2     ONLINE       0     0     0

errors: No known data errors

A példa szerint minden megfelelően működik.

Előzetesen már szó esett róla, hogy a ZFS képes a tárolt adatok sértetlenségének ellenőrzésére. Az új állományrendszerek létrehozásánál ez a lehetőség automatikusan aktiválódik, de tetszés szerint letiltható:

# zfs set checksum=off tarolo/felhasznalok

Ez a lépés viszont nem feltétlenül jó döntés, mivel az adatintegritás megtartásához felhasznált ellenőrző összegek nagyon kevés helyet foglalnak és meglehetősen hasznosak. Emellett semmilyen észlelhető lassulást nem okoznak az állományrendszer használata során. Ha engedélyezzük, a ZFS ilyen ellenőrző összegek segítségével folyamatosan figyelni tudja az adatok épségét. Ezt az ellenőrzést a scrub paranccsal válthatjuk ki. Nézzük meg például a tarolo esetében:

# zpool scrub tarolo

Ez a vizsgálat a tárolt adatok mennyiségétől függően nagyon sokáig is eltarthat, illetve rengeteg lemezműveletet foglal magában, ezért egyszerre csak egy ilyen futtatása javasolt. Miután befejeződött, a tároló állapota az eredményének megfelelően frissül, amelyet közvetlenül utána le is kérdezhetünk:

# zpool status tarolo
 pool: tarolo
 state: ONLINE
 scrub: scrub completed with 0 errors on Sat Aug 30 19:57:37 2008
config:

	NAME        STATE     READ WRITE CKSUM
	tarolo      ONLINE       0     0     0
	  raidz1    ONLINE       0     0     0
	    da0     ONLINE       0     0     0
	    da1     ONLINE       0     0     0
	    da2     ONLINE       0     0     0

errors: No known data errors

A példában látható az utolsó ellenőrzés ideje. Ezen lehetőség használatával hosszú időn keresztül szavatolni tudjuk az adataink épségét.

A Z állományrendszerrel kapcsolatos további beállítási lehetőségekről a zfs(8) és zpool(8) man oldalakon olvashatunk.