ZFS

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(új oldal (to be continued))
 
a (typo, pontosítás)
145. sor: 145. sor:
 
=== Linuxos gép telepítése zfs-sel ===
 
=== Linuxos gép telepítése zfs-sel ===
   
Tegyük fel, hogy van egy gépünk, benne két 256GB-os SSD-vel, 16+GB RAM-mal, és hogy erre Linuxot szeretnénk telepíteni. Az alábbiakban leírom ennek a folyamatnak néhány lépését és elmagyarázom a tervezői döntéseket.
+
Tegyük fel, hogy van egy gépünk, benne két 256GB-os SSD-vel, 16+GB RAM-mal, és hogy erre Debian/GNU Linuxot szeretnénk telepíteni. Az alábbiakban leírom ennek a folyamatnak néhány lépését és elmagyarázom a tervezői döntéseket.
   
 
# Bootoljunk be valamilyen live médiumról (pl. [http://grml.org/ GRML]-es USB-kulcsról).
 
# Bootoljunk be valamilyen live médiumról (pl. [http://grml.org/ GRML]-es USB-kulcsról).
158. sor: 158. sor:
 
#* Ezért csináljunk még egy RAID1-tömböt (az első a <tt>/boot</tt> helye lesz), amin majd a root filerendszer, a <tt>/usr</tt> ill. a <tt>/var</tt> nagy része kap helyet, LVM-ben.
 
#* Ezért csináljunk még egy RAID1-tömböt (az első a <tt>/boot</tt> helye lesz), amin majd a root filerendszer, a <tt>/usr</tt> ill. a <tt>/var</tt> nagy része kap helyet, LVM-ben.
 
#* A maradék helyen hagyjunk egy-egy partíciót, amit majd a zfs fog használni (a továbbiakban feltételezem, hogy ez a két partíció az <tt>sda4</tt> ill. az <tt>sdb4</tt>).
 
#* A maradék helyen hagyjunk egy-egy partíciót, amit majd a zfs fog használni (a továbbiakban feltételezem, hogy ez a két partíció az <tt>sda4</tt> ill. az <tt>sdb4</tt>).
# Hozzuk létre azt a könyvtárat, amibe majd telepítünk: <pre>mkdir /t</pre>.
+
# Hozzuk létre azt a könyvtárat, amibe majd telepítünk: <pre>mkdir /t</pre>
 
# Hozzuk létre a zpoolt: <pre>zpool create -o ashift=12 -o autoexpand=on -R /t tank mirror /dev/sd[ab]4 -O atime=off -O compression=gzip-9 -O devices=off -O setuid=off -O exec=off -O dedup=on -O com.sun:auto-snapshot=false -O xattr=off -O mountpoint=/ -O canmount=off</pre>
 
# Hozzuk létre a zpoolt: <pre>zpool create -o ashift=12 -o autoexpand=on -R /t tank mirror /dev/sd[ab]4 -O atime=off -O compression=gzip-9 -O devices=off -O setuid=off -O exec=off -O dedup=on -O com.sun:auto-snapshot=false -O xattr=off -O mountpoint=/ -O canmount=off</pre>
 
#* Magyarázat: <tt>ashift=12</tt> -- csak a pool létrehozásakor állítható proprety; azt adja meg (log2 alapon), mekkora "szektormérettel" dolgozzon a zfs.
 
#* Magyarázat: <tt>ashift=12</tt> -- csak a pool létrehozásakor állítható proprety; azt adja meg (log2 alapon), mekkora "szektormérettel" dolgozzon a zfs.

A lap 2012. október 12., 09:09-kori változata

A ZFS az Oracle (leánykori nevén Sun) fájlrendszere, amely egyfajta kötetkezelőt és szoftveres RAID-megvalósítást is tartalmaz. Fő előnyei:

  • Rendkívül kényelmes adminisztráció;
  • SSD-k ésszerű használata (cache-ként);
  • ellenőrző összegek (észleli és esetenként javítja az amúgy észrevétlen hibákat);
  • a látszólag különböző rétegbe való funkciók (RAID, kötetkezelés, fájlrendszer) integrálása révén pl. RAID-helyreállításkor csak a foglalt területeket kell szinkronizálnia;
  • röptömörítés;
  • in-line deduplikáció;
  • stb.

2012-ben Solarishoz, IllumOS-származékokhoz (OpenSolaris, NexentaStor stb.), FreeBSD-hez és Linuxhoz létezik elérhető implementáció. Az Apple egy darabig dolgozott egy Mac OS X-porton, de úgy tűnik, felhagyott vele.

Eredetileg a Solarishoz fejlesztették ki; ez akart lenni a Nagy Végső Válasz (majdnem akkora, mint a 42) az összes fájlrendszerproblémára ("The Last Word in Filesystems").

Tartalomjegyzék

1 Alapfogalmak, építőelemek

  • 'Pool: kb. az LVM VG megfelelője. Fizikai adattárolók (vdevek, l. lejjebb) összessége; az ezekben rendelkezésre álló tárhelyet oszthatjuk ki zvol-ok és zfs-példányok között.
  • vdev: kb. az LVM PV megfelelője. Egy fizikai diszk, vagy egy több diszkből álló tömb.
    • A poolban tárolt adatokat a zfs RAID0-szerűen szétteríti az egyes vdevekre.
    • Egy pool bővíthető újabb vdevekkel;
    • a poolhoz hozzáadott vdevek eltávolítása (speciális esetektől eltekintve) nem lehetséges.
      • Bővítéskor nem történik újracsíkozás; az újonnan felírt adatok azonban már részben az új vdev(ek)re is kerülnek.
    • vdevek lehetséges típusai:
      1. file (nem javasolt);
      2. diszk (vagy partíció);
      3. mirror (RAID1, akárhány diszkből);
      4. raidz, raidz1 (kb. RAID5);
      5. raidz2 (kb. RAID6);
      6. raidz3 (csíkozott, paritásos, három paritásblokkot használó elrendezés; így bármely három diszk kiesését túlélheti);
      7. spare (melegtartalék);
      8. log (más néven ZIL; a szinkron írások szerializálására szolgáló opcionális írás-cache, pl. SSD);
        • A log maga is lehet mirror; sőt, ajánlatos mirrorba tenni.
      9. cache (a poolhoz tartozó opcionális másodlagos olvasás-cache, pl. SSD).
        • A zfs terminológiájában az ilyen cache az "L2ARC" (Level 2 Adaptive Replacement Cache).
        • A cache jelenleg nem lehet sem mirror, sem raidz[123].
        • A cache alapértelmezés szerint csak a véletlen (nem prefetch-elhető) olvasásokat cache-eli.
  • dataset: olyan objektum, amelynek a pool helyet biztosít. Típusai:
    • zvol: kb. az LVM LV megfelelője. Egy blokkeszköz, amin tetszőleges fs-t létrehozhatunk (vagy pl. odaadhatjuk egy virtuális gépnek, mint diszket).
      • Snapshotolható, dedpulikálható, röptömöríthető anélkül, hogy a benne levő fs-nek erről tudnia kéne.
      • Kiajánlható iSCSI-val.
      • Csak speciális esetben érdemes használni; többnyire jobb:
    • filesystem: egy zfs-példány.
      • Mountolható, snapshotolható, deduplikálható, röptömöríthető stb.
      • Kiajánlható NFS-sel, CIFS-szel (windows-os share-ként).
    • snapshot: egy zvol vagy filesystem adott pillanatbeli, csak olvasható képe.
    • clone: egy snapshot írhatóvá tett másolata; annyi helyet foglal, amennyi módosítást tárol az eredeti snapshothoz képest.
  • A ZFS logikai/funkcionális részei:
    • ZFS POSIX Layer (ZPL) -- ettől látszik fájlrendszernek.
    • Data Management Unit (DMU).
      • Ez egy általános objektumtároló; ez szavatolja az adatintegritást (ellenőrző összegekkel).
      • Használható a ZPL nélkül is (ez a zvol); pl. közvetlenül épülhet rá adatbázis, vagy csinálhatunk egy zvolban tetszőleges egyéb fs-t.
    • Storage Pool Allocator (SPA).
      • Ez kezeli az egész alatti fizikai diszkeket.
      • Ez tömörít, blokkszinten; emellett automatikusan megtalálja a "lukakat" a fájlokban és azoknak nem allokál helyet.

2 Jellemzői

  • Rettenetesen nagy bír lenni (logikailag több adatot tud tárolni, mint amennyi a Földön található összes anyag segítségével fizikailag tárolható lenne).
    • A meta-adatok is dinamikusan nőnek: akárhány fájl lehet egy könyvtárban, akárhány fájl lehet összesen stb.
    • Emiatt csak 64bites rendszeren ajánlott használni.
  • Nem kell előre eldöntenünk, mi mekkora legyen: a rendelkezésre álló helyből ("pool") a zfs maga gazdálkodik (nyilván állíthatunk be korlátokat).
    • Egy-egy "fájlrendszer", amit létrehozunk, igazából csak a benne tárolt fájlok adminisztratív csoportosítását szolgálja.
  • Hierarchikus. A tank poolban lehet egy tank/srv nevű zfs-példány, abban egy tank/srv/www, abban egy tank/srv/www/www.domain.com stb. Ezek nemcsak alkönyvtárak, hanem különálló filerendszerek;
    • önállóan mountolhatóak,
    • snapshotolhatóak
    • kvótázhatóak, és
    • alapbeállításaikat a felmenőiktől öröklik. Ez állati kényelmes.
    • Egyetlen zfs mount -a paranccsal be lehet mountolni az összeset egyszerre, akkor is, ha másik gépbe raktuk a poolt, mert a mountpoint is benne tárolódik, nem az fstabban (kivéve, ha legacy-ra állítjuk a mountpointot).
  • Architektúrafüggetlen.
    • A byte-sorrendet úgy kezeli, hogy a blockokban egy bit jelöli, az adott block big vagy little endian;
      • az írás mindig natív byte-sorrenddel történik;
      • olvasáskor byte-csere kell, ha a beolvasott blokk byte-sorrendje nem azonos a CPU-éval.
  • A blokkméret változó (de extenteket nem használ).
  • NTFS-jellegű ACL-eket valósít meg (NFSv4 ACL; jobb, mint a POSIX ACL).
  • Fájlok tulajdonosa windowsos SID is lehet (nemcsak unixos UID/GID).
  • Tranzakciókezelést használ; a lemezen elvileg mindig csak konzisztens állapot létezik, tehát elvileg sosem kell fsck-zni.
    • Sosem helyben írja felül az adatokat; az új adatokat új helyre írja, majd "átállítja az érvényes adatra mutató pointert".
    • Így automatikusan előáll egy olcsó (értsd: gyors) snapshot is (hiszen az eredeti adatok még megvannak). A snapshotolás overheadje csak annyi, hogy ezeknek a "pointereknek" a snapshot létrehozásakor érvényes állapotát kell megőrizni.
  • Integritásellenőrzés is van benne, így elvileg véd a kábelhibákból és hasonlókból eredő adathibák ellen.
    • Ha olvasáskor hibát talál, a poolban meglevő redundancia segítségével javítja; ha nincs redundancia, I/O hibát kapunk, és nem férünk hozzá a hibás adathoz. Ez nem mindig jó.
  • Blokkszintű deduplikációt valósít meg, ha szeretnénk.
  • Van "RAID-Z", ami elegendően bonyolult ahhoz, hogy ne lehessen azonnal minden részletében felfogni a működését; a fő előnyei elvileg:
    • Nincs szükség read-modify-write-ra (mint a RAID5/RAID6 esetében).
    • Állítólag elkerüli azt a problémát, hogy ha az adatok kiírása után, de a paritás kiírása előtt megy el az áram, akkor inkonzisztens lesz a paritás.
  • Az integritásellenőrzésnek köszönhetően akkor is kijavítja a hibákat, ha az olvasás látszólag sikerül (tehát amikor egy hagyományos RAID-megvalósítás nem nyúlna a paritáshoz).
  • Resync ("resilvering") esetén csak azokat a blokkokat másolja, amikben tényleg van adat.
  • Érdemes "scrub"-okat (teljes integritásellenőrzést) ütemezni; ilyenkor a háttérben végigolvassa az adatokat és kijavítja az esetleges hibákat, ha van redundancia. Ha nincs, akkor megtudjuk, melyik fájlunk vált olvashatatlanná. A scrub -- legalábbis Linuxon -- elég lassú tud lenni, és sajnos nem lehet részletekben elvégezni.
  • A "fontos" metaadat-blokkokat több példányban tárolja, mint a kevésbé fontosakat.
    • Egyébként egyes fs-ek szintjén is kérhetjük, hogy az adott fs-t két vagy több példányban tárolja; így akár egyetlen diszken is tudjuk a fontos adatainkat -- nyilván jókora sebességveszteség árán -- redundánsan tárolni. Ez a hibás szektorok ellen véd, a teljes diszk kiesése ellen nyilván nem. Főként notebookon lehet hasznos.
  • Automatikusan csíkoz a rendelkezésre álló vdevek fölött.
    • Ha új vdevet rakunk be, arra is elkezd csíkozni és a tranzakció-alapú írások miatt idővel, szép lassan, minden adat az összes diszkre szétterül.

2.1 Deduplikáció

  • Többféle hash közül választhatunk, és azt is előírhatjuk, hogy hash-egyezés esetén az adatokat hasonlítsa is össze byte-ról byte-ra, nehogy egy esetleges -- amúgy rendkívül valószínűtlen -- hash-ütközés az adatok sérülését okozza.
  • Nem kötelező az összes adatot deduplikálni; szelektíven is bekapcsolhatjuk (egyes datasetekre külön-külön).
    • De a deduplikációs táblázat az egész poolban közös, tehát a poolon belüli különböző datasetek között is megvalósul a deduplikáció.
  • A deduplikáció rendkívül memóriaigényes:
    • Kb. 3-400 byte memória (L2ARC) kell minden blokkhoz; a blokkméret változó, de legfeljebb 128k; ha kis fájljaink vannak, egy-egy fájl egy blokk (és persze majdnem minden nagy fájl vége egy 128k-nál kisebb blokk).
    • Ha L2ARC-ban van a deduplikációs táblázat (DDT), akkor minden max. 128k-nyi L2ARC-hoz kb. 200 byte memória kell.
    • Ökölszabályok: ne deduplikáljunk, ha
      • nem számítunk legalább 50% hely-megtakarításra ÉS
      • nincs legalább 24, de inkább 32GB RAMunk.
  • A deduplikáció, főként, ha nincs megtámogatva SSD-s cache-sel, jelentősen ronthatja a szekvenciális olvasás sebességét, hiszen fragmentációt okoz.
  • Ha nincs elég RAMunk (vagy SSD-s cache-ünk), a deduplikáció több nagyságrenddel ronthatja az írás sebességét. Ez nem fog azonnal kiderülni, csak akkor, amikor a DDT elér egy bizonyos méretet.
  • Jó tudni: az ARC (az operatív memóriában levő cache) maximális mérete alapértelmezés szerint az összes RAM háromnegyede, vagy az összes RAM mínusz 1GB (amelyik nagyobb). Ennek alapértelmezés szerint maximum 25%-át fordítja metaadatok (mint pl. a DDT) cache-elésére a zfs. Mindkét paraméter állítható (utóbbi neve zfs_arc_meta_limit); ha deduplikálunk, érdemes lehet növelni őket.
  • A DDT nyilván a diszken is helyet foglal; ha sok az egyedi adat, a táblázat könnyen nagyobbra nőhet, mint amennyit a kevés duplikátumon megspórolunk.
  • A kiírt blokkok akkor kapnak DDT-bejegyzést, ha kiírásuk pillanatában aktív a datasetjükben a deduplikáció. Következmények:
    1. A kikapcsolt deduplikáció mellett kiírt blokkok nem lesznek deduplikálva (nyilván).
    2. Ha később bekapcsoljuk a deduplikációt, és az iménti blokkok újabb példányát írjuk ki, a DDT szempontjából ezek lesznek ezeknek a blokkoknak az első példányai, vagyis szintén nem takarítunk meg tárhelyet.
    • Ha utólag akarunk deduplikálni sok adatot, valószínűleg a zfs send/receive (l. később) a legelegánsabb megoldás.
  • A deduplikáció aszinkron művelet; a rendszer a háttérben végzi el a ZIL (a write cache) ürítésekor.
    • Így a szinkron írások nem kell, hogy megvárják;
    • cserébe a ZIL hamarabb megtelhet, ha sok, amúgy deduplikálható szinkron írást kell tárolnia.

3 ZFS Linux alatt

  • Linuxra párhuzamosan készült egy userspace és egy kernelspace megvalósítás.
    • A kernelspace implementáció licencproblémák miatt sosem kerülhet bele a hivatalos kernelbe (az OpenSolarist, aminek a ZFS a része, a CDDL alatt teszik elérhetővé, ez pedig jogilag nem kompatibilis a GPL-lel). Az egyetlen megoldás az lenne, hogy valaki nulláról újraírja a ZFS-t (úgy, hogy az adatstruktúrák és algoritmusok ugyanazok, de a kód teljesen új).
    • A FUSE-os megoldásnak nincsenek ilyen gondjai, mivel a GPL-nek nem kell megfelelnie.
    • Jelen sorok írásakor (2012. őszén) a kernelspace-verzió használata az ajánlott; a zfs-fuse fejlesztése megtorpant, a fejlesztők már szintén a zfsonlinuxot (a kernelbeli megvalósítást) használják.
      • A zfs-fuse-t ugyanakkor egyszerűbb telepíteni, úgyhogy a zfs kipróbálására nagyon is alkalmas.
      • Vigyázat! A zfs-fuse 2012. vége felé aktuális, 0.7.0-ás verziója bizonyos terhelések mellett instabil (nálam nem okozott adatvesztést, de rendelkezésreállási problémákat igen).
      • A zfs-fuse régebbi pool- és zfs-verziókat implementál, mint a zfsonlinux, így a zfsonlinuxszal létrehozott poolt nem használhatjuk vele (de fordítva igen).

4 Esettanulmányok

4.1 Linuxos gép telepítése zfs-sel

Tegyük fel, hogy van egy gépünk, benne két 256GB-os SSD-vel, 16+GB RAM-mal, és hogy erre Debian/GNU Linuxot szeretnénk telepíteni. Az alábbiakban leírom ennek a folyamatnak néhány lépését és elmagyarázom a tervezői döntéseket.

  1. Bootoljunk be valamilyen live médiumról (pl. GRML-es USB-kulcsról).
    • Haladók készíthetnek maguknak saját, a zfs-támogatást eleve tartalmazó grml-t; kulcsszó: "grml remastering". Aki látott már FAI-t, annak ismerős lesz.
  2. Rakjuk fel a futó grml-re a http://ppa.launchpad.net/zfs-native repositoryból a következő csomagokat:
    apt-get install zfsutils zfs-dkms spl-dkms
    • Előfordulhat, hogy ehhez az Ubuntuban levő libc6-ot is fel kell raknunk (ha újabb, mint ami a grml-ünkön van); másik lehetőség a zfs-es csomagok újrafordítása a grml-es környezetben.
  3. Particionáljuk a diszkeket (SSD-ket); lehetőleg használjunk GPT-t.
    • A biztonság kedvéért csináljunk külön partíciókat a /boot-ot tartalmazandó RAID1-tömb számára. Elvileg ugyan tud LVM-ről bootolni a grub, de az ördög nem alszik.
    • Ne felejtsünk el egy párszáz szektorból álló, bios_grub flaggel ellátott partíciót csinálni a diszk elejére (mondjuk a 34-edik szektortól az 511-edikig), hogy a grub tudja hova másolni magát.
    • A RAID-tömbünket alkotandó partíciókat lássuk el a raid flaggel.
    • Mivel a zfsonlinux "out of tree" modul, előfordul, hogy pl. kernelupgrade után nem fordul le helyesen; emiatt hasznos, ha be tudunk bootolni nélküle is.
    • Ezért csináljunk még egy RAID1-tömböt (az első a /boot helye lesz), amin majd a root filerendszer, a /usr ill. a /var nagy része kap helyet, LVM-ben.
    • A maradék helyen hagyjunk egy-egy partíciót, amit majd a zfs fog használni (a továbbiakban feltételezem, hogy ez a két partíció az sda4 ill. az sdb4).
  4. Hozzuk létre azt a könyvtárat, amibe majd telepítünk:
    mkdir /t
  5. Hozzuk létre a zpoolt:
    zpool create -o ashift=12 -o autoexpand=on -R /t tank mirror /dev/sd[ab]4 -O atime=off -O compression=gzip-9 -O devices=off -O setuid=off -O exec=off -O dedup=on -O com.sun:auto-snapshot=false -O xattr=off -O mountpoint=/ -O canmount=off
    • Magyarázat: ashift=12 -- csak a pool létrehozásakor állítható proprety; azt adja meg (log2 alapon), mekkora "szektormérettel" dolgozzon a zfs.
      • Azért állítjuk 4k-ra, mert lehet, hogy később kerül 4k-s szektorokat használó diszk a poolba.
      • Azért nem állítjuk még nagyobbra, mert az SSD-nek valószínűleg 128k körüli (vagy még nagyobb) méret kedvezne, azzal viszont túl sok helyet pazarolnánk el.
    • -o autoexpand=on -- ha megnő a poolt alkotó vdev, a zfs kezdje el használni a több helyet anélkül, hogy ezt külön kérnénk.
    • -R /t -- állítsuk az altroot property-t /t-re. Így, amíg a live rendszeren dolgozunk, a /t (valójában /t/mountpoint, de a mountpoint "/" lesz) alatt jönnek létre az új zfs-eink, de ha később a valódi rendszert bootoljuk be, minden az elvárt helyén lesz.
    • tank -- így fogják hívni a létrehozandó poolt. A "tank" név konvenció; lehetne bármi más is.
    • mirror /dev/sd[ab]4 -- egy tükrözött (tehát RAID1-szerű) vdevet adunk meg, amit a felsorolt két partíció fog alkotni.
    • -O atime=off -- alapból kikapcsoljuk az atime update-eket az uj fs-eken (ahol kell, majd külön bekapcsoljuk). Ezzel részben nyerünk egy kis teljesítőképességet, részben pedig elkerüljük az SSD túlzott "koptatását".
      • -o-val a poolra, -O-val pedig a pool gyökerében levő zfs-példányra vonatkozó opciókat (propertyket) állítjuk be.
      • A pool gyökerében beállított tulajdonságok (néhány kivételtől eltekintve) öröklődnek a gyermek-fájlrendszerekre; az alapértelmezéseket így csak egyszer, a pool gyökerén kell beállítanunk, de ahol akarjuk, felülbírálhatjuk őket.
    • -O compression=gzip-9 -- a tömörítés a mai CPU-k korában majdnem ingyen van; az SSD-n viszont egyrészt aránylag szűk a hely, másrészt minél kevesebbet írunk rá, annál hosszabb lesz az élettartama, tehát duplán megéri tömöríteni. Ha valamelyik konkrét fájlrendszernél rettentően számít a sebesség, akkor ott érdemes lehet simán on-ra állítani a tömörítést (az sokkal gyorsabb, mint a gzip-9, de még mindig tömörít), vagy akár ki is kapcsolni.
    • -O devices=off -- alapból nem akarjuk értelmezni a device node-okat a poolban levő fájlrendszerekben; ahol mégis, ott majd kifejezetten bekapcsoljuk.
    • -O setuid=off -- alapból nem szeretnénk, ha a setuid/setgid bitek hatásosak lennének (ahol kell, majd bekapcsoljuk).
    • -O exec=off -- alapból nem kell, hogy a fájlrendszerekben levő fájlok végrehajthatóak legyenek.
    • -O dedup=on -- ez talán a legmegkérdőjelezhetőbb döntés. A deduplikáció bekapcsolása általában nem javasolt, mert nagyon memóriaigényes és súlyos lassuláshoz vezethet (ha a DDT nem fér el az ARC-ben, vagy pláne ha az L2ARC-ben sem). Miért kapcsoltam be mégis:
      • Adjunk felső becslést a DDT memóriaigényére! Az SSD aránylag kicsi (256GB), és nem is az egészet használjuk zfs-sel. A DDT mérete szempontjából a kis blokkméret a legrosszabb (az egyedi blokkok számával arányos a mérete). Az ashift=12 miatt a legkisebb lehetséges blokkméret 4k. Ha a 256GB-ot 256 gibibyte-nak vesszük, 67108864 darab 4k-s blokk fér el rajta. Ha ezt felszorozzuk 400-zal, azt kapjuk, hogy a DDT mérete legfeljebb 25GB lehet. A valóságban ennél jóval kisebb táblára számíthatunk, mivel nagy fájlok is lesznek az SSD-n (amelyeknél így 4k-nál jóval nagyobb, általában 128k lesz a blokkméret). Ha minden blokk 128k-s lenne, az 1GB-ot sem érné el a DDT mérete.
      • Ha nem fér el a DDT az ARC-ben (RAM-ban), akkor még mindig elférhet az L2ARC-ben. Itt most nem lesz L2ARC, mert nincs a két SSD-nél kisebb, de jóval gyorsabb tárolónk. Így, ha a DDT egy része kiszorul a RAMból, a diszkről kell be-beolvasgatni; ez általában nagyon lassú lenne a sok seek miatt, de itt most a diszk egy SSD, ami szinte ingyen seekel, tehát arra számítok, hogy a DDT olvasgatása nem lassítja le nagyon az írást.
      • Szintén az SSD-nek köszönhetően a deduplikáció okozta fragmentációtól sem várok jelentős lassulást.
      • Az SSD élettartama tekintetében két hatás áll egymással szemben: egyfelől a DDT karbantartásával összefüggő írási műveletek csökkentik az élettartamot, másfelől viszont a sikeres deduplikációnak köszönhetően kevesebb adatot kell kiírni. Mivel minden új blokk kiírásakor módosul a DDT, extrém esetektől eltekintve nem valószínű, hogy a deduplikációval megtakarított írásokat is figyelembe véve összességében kevesebbet írnánk, mint kikapcsolt deduplikációval.
      • Másfelől viszont valamennyi helyet megtakaríthatunk, és így több szabad hellyel gazdálkodhat az SSD wear leveling logikája -- arról nem is beszélve, hogy lassabban futunk ki a helyből. (Kivéve, ha döntően egyediek a blokkok, mert akkor a DDT feleslegesen foglalja a helyet.)
        • Fontos: ha nem SSD-nk lenne, nem lenne elég "valamennyi" helyet megtakarítani ahhoz, hogy megérje deduplikálni. Sok megtakarítás kellene hozzá.
        • Nehéz előre megmondani, mennyire lesznek deduplikálhatóak az adatok.
    • -O xattr=off -- alapból nem szeretnénk bővített attribútumokat használni. Ezekre többnyire nincs szükségünk (ha pedig igen, akkor tudunk róla). 2012. vége felé egyébként a zfsonlinuxban elég lassú az xattr-megvalósítás; dolgoznak egy jobb megoldáson, ami a ZFS 24-es poolverziójában bevezetett "renszerattribútumokat" használná erre a célra, de egyelőre nincs kész.
    • -O mountpoint=/ -- azt gondolhatnánk, hogy így majd zfs lesz a root filerendszerünk, de nem; l. az alábbi opciót is:
    • -O canmount=off -- így maga a pool gyökere nem fog bemountolódni, csak öröklik tőle a beállításokat a gyermek-filerendszerek.
    • -O com.sun:auto-snapshot=false -- ez nem "gyári", "natív" property (tulajdonság), hanem a zfs-auto-snapshot script működését befolyásolja (tetszőleges saját címkéket helyezhetünk el a zpool-beli objektumokon namespace:label=value jelleggel; ezek szintén öröklődnek a gyermek-objektumokra). Azt kérjük, hogy alapértelmezés szerint ne snapshotolja a fájlrendszereinket a zfs-auto-snapshot; amelyikről szeretnénk rendszeresen snapshotot csinálni, azon majd true-ra állítjuk ezt a property-t.

5 Források

Személyes eszközök