Válaszolok mindenkinek egyszerre, ha szabad, legjobb tudásom szerint (pontosítást, helyesbítést, javítást szívesen fogadok)! :-) Bocsi, hosszú!
Ha nincs elég erőforrás a ZFS-hez, akkor más után kell nézni (pl. MD+LVM+ext4 :-). A ZFS fájlrendszer, kötetkezelő és redundancia szolgáltató egyben. Ennek erőforrás igénye van. El kell fogadni, hogy ha nincs ilyesmire szánható, megfelelő mennyiségű CPU és RAM, akkor el kell engedni a ZFS-t. Olyan nem nagyon van, hogy lecsupaszítani. Olyan van, hogy korlátozod a memória felhasználást, és az kiad valami teljesítményt (ZFS szinten), ami vagy megfelel a felhasználásnak vagy kevés.
A ZoL elműködik 4 GB memóriával (mármint, hogy 4 GB jut a ZoL-nak, nem teljes rendszer memória!), a FreeBSD-s ZFS inkább 8 GB-ot szeret minimumként magáénak tudni (FreeNAS pl.). De persze ne erre építse senki a rendszertervét, ezek a minimumok, amik ahhoz kellenek, hogy irtó lassulás ne legyen. Én Linux-on 8GB-t (általános rendszer, nem storage célú), FreeBSD alapon 16 GB-ot javaslok minimumnak (persze ha FreeNAS storage, akkor inkább 32+ GB legyen). Ezek a számok csak több 10 TB pool méret felett lesznek csak kevesek. A ZFS belépési küszöbe eléggé magas RAM terén. Manapság eléggé olcsó a RAM és a legtöbb gépbe tehető is belőle jó sok, így nem kell ez gondot okozzon. Ha a gép erre nem képes, az azt jelenti, hogy nem való ZFS alá, nem a ZFS a hibás.
Itt még megjegyzendő, hogy sokáig riogattak mindenkit, hogy ha nem ECC RAM van a gépben, akkor egy esetleges RAM hiba esetén az egész pool oda lesz, mert a rossz RAM-mal újraszámolt checksum mind rossz lesz, ami tönkreteszi a pool-on lévő adatokat. Ez butaság, rossz RAM modul esetén ZFS-nél sem lesz több adat hiba a pool-on, mint bármi más rendszerrel lenne. Az a különbség, hogy a ZFS majd a scrub során legalább ezt észreveszi (míg egy ext4 esetén sose derül ki). Más oldalról ZFS alá a szerver hardverek ideálisak, amik általában ECC képesek, így én éles környezetbe mindenkit bátorítok az ECC RAM használatára ZFS esetén (is). Játszós teszt rendszeren mindegy.
A felhasznált memória jelentős része az ARC (Adaptive Replacement Cache), ami egy olvasási gyorsítótár annyi különbséggel, hogy erre a rendszernek van szüksége inkább. Ebből minél több van, annál jobb a rendszer általános teljesítménye (nem csak user adat van benne - sőt -, hanem rengeteg metaadat a ZFS működéséhez). Ehhez kell igazából a "sok" memória. Az L2ARC a nevéből is gondolhatóan a másodszintű ARC (lenne). Ez a régi idők maradéka, amikor a CPU-k memória címzése korlátos volt, és nagyon drága volt a RAM. Ilyenkor tettek be L2ARC-nak a pool-nál gyorsabb tárolót. Ez a RAM-ban lévő ARC és a pool közötti olvasási réteget ad(na ha használnánk). Manapság mindenki azt mondja (jogosan), hogy ki kell maxolni a RAM-ot a gépben mielőtt L2ARC kerülne a pool-ba. Ha így sem elég, akkor kell egy több RAM-ot kezelő gép, nem L2ARC. :-) Persze lehet kísérletezni (sok fórumon olyan szintig értik félre a működést és az értelmet, hogy egyazon kommersz SSD-t osztanak szét SLOG és L2ARC számára partíciókra - ez nagyon rossz ötlet). Vannak olyan speciális esetek, amikor jól jön az L2ARC mégis (nagyon nagy, jellemzően csak olvasott, de gyakran olvasott adathalmazok, amik mellett van más kisebb, de még gyakrabb olvasott adat is). Azt tudni kell, hogy az L2ARC is igényel RAM (ARC) területet, mert a ZFS az ARC-ban tárolja az L2ARC-ban elérhető adatok indexét. Szóval kevés RAM esetén pláne nem kell L2ARC, mert a sokkal hasznosabb ARC-ból rabol el helyet a működése.
A ZIL (ZFS Intent Log) az írási napló. Ez az írások lényege (mert a ZFS ugye Copy on Write). Alapból a memóriába kerül az írási log, majd onnan (az alapértelmezetten) a pool-on lévő ZIL-be, ahonnan (alapértelmezetten) 5 mp-ként a pool-on lévő végleges helyére a tartalma (ez nem a ZIL-ből, hanem szintén a memóriából, a ZIL-ből nem olvas vissza a rendszer, hogy kiírja a helyére). A ZIL-t a rendszer csak írja, folyamatosan. Egy esetben kerül csak olvasásra, ha egy összeomlás után helyre akar állni a ZFS, és a pool-on lévő adatokra rá akarja vezetni a ZIL tartalmát (az összeomlás előtti utolsó 5 mp-et). Tehát a ZIL nem gyorsítja az írás sebességét, azt a pool fogadási képessége határozza csak meg.
Az SLOG (Separate Intent Log) egy külső eszköz, de a pool része, ahol a ZIL helyet kap, a pool helyett. Régen a ZIL elvesztése pool elvesztéssel járt, ezért javasolták a tükrözését, de a mostani ZFS verzióknál erre nincs szükség (sőt, adott esetben lassabb lehet, mint egyetlen SLOG meghajtóval). Ha a ZFS rendszer SLOG hibát észlel, akkor simán visszavált a pool ZIL-re, és megy tovább hiba nélkül (mert ugye csak ír a ZIL-be, így nem okoz kárt, ha e közben hibát talál - persze ha ad abszurdum pont ilyenkor omlik össze a rendszer, akkor adatveszés lesz, max. 5 mp-nyi).
As SLOG célszerűen a pool-nál (jóval) gyorsabb írásra képes, magas IOPS értékű eszköz. A ZIL léte csak szinkron írásnál "tűnik fel". A ZFS a szinkron írásokat akkor jelzi vissza sikeresnek a kliens felé, ha a write log tartalma nem-felejtő tárolóba került nyugtázottan. Pl. VMware csak szinkron módon használ NFS-t datastore-nak. Namost ha egy nagy IOPS-es SSD kerül be SLOG-nak a pool-ba, akkor annyival lesz gyorsabb a szinkron írás IOPS (nem a throughput), amennyivel magasabb az SLOG IOPS-3 a pool-énál. Ezt leginkább erősen párhuzamos szinkron írásnál venni észre (pl. VM-ek futnak NFS-en keresztül a ZFS pool-on).
Az L2ARC hasznossága utáni másik félreértés itt szokott lenni, hogy bármilyen SSD jó ZIL-nek, mert mind gyors és magas az IOPS. Ez egy oldalról igaz, más oldalról saját magunk becsapása. Mert tényleg gyorsabbak, mint a pool jellemzően pörgő lemezei, de a legtöbb kommersz SSD DRAM-ot használ gyorsításra, onnan általában SLC NAND-ba ír (vagy közvetlen az MLC-be), majd onnan vezeti át később az MLC (TLC, QLC) NAND-ba az adatot a végleges helyére. A szinkron írást vagy a DRAM-ba, vagy az SLC-be írás után nyugtázza (a DRAM-os esetben áramkimaradás esetén adatvesztés lesz a ZIL-ben!), ráadásul nagyon lelassul, mikor a DRAM/SLC megtelik (pl. burst random írás a pool-ba).
Ellenben a vállalati PLP (Power Loss Protection - általában supercap-pel) képes SSD-k a fogadás után azonnal nyugtázzák a szinkron írást, mert a védelem miatt biztosan ki tudják írni nem felejtő tárba az adatot, bármilyen gyorsítást is használnak. Ezek általában nem is lassulnak le folyamatos terhelés alatt. Ilyen kedvelt PLP SSD az Intel Optane 4800-as sorozata (a 800-as, 900-as gyors, de nincs PLP!), vagy a Samsung SM-xx3-ra végződő vállalati SSD-inek jó része (a PMxx3 nem PLP-s). Fontos, hogy magas legyen az SLOG SSD írási tűrőképessége (TBW értéke), mert csak ír rá a rendszer, sokat.
A másik fontos dolog az SLOG-gal kapcsolatban a mérete. A minél nagyobb annál jobb itt nem igaz, sőt. Csak árt a nagy SLOG. Az SLOG méretének annyinak kell lennie, amennyi adatot a gép a ZIL kiírások közötti idő alatt (gyárilag 5 mp) fogadni képes írás céljából. Ez 1x1 GbE kapcsolat esetén 125 MB * 5 mp = 625 MB (!) összesen. Ha 1x10 GbE kapcsolat van, akkor lesz 6.25 GB az igény (!) összesen. Emiatt az SLOG-nak szánt meghajtókat leméretezik (overprovision) a gyári méret alá jóval (8 vagy 16 GB jellemzően), és így a "felszabadult" helyet az SSD kontrollere még a cellaterhelés kiegyenlítésére is el tudja használni (ez sokkal jobb módszer, mint a kicsi partíció létrehozása). Sajnos a gyárilag ilyen méretű meghajtók SSD-s léptékkel lassúak (minél nagyobb, annál több csip, annál gyorsabb párhuzamos írás), és általában nincs PLP (Pl. Intel Optane M10 sorozat ilyen, ami ideális lenne, de mégsem az).
Deduplikáció: az OpenZFS készítői, és az egyes megvalósítások készítői is arra biztatnak mindenkit, hogy _ne_ használjon deduplikációt. Ez is a régi idők maradéka, amikor a drága és kicsit HDD-k mellett a tárolható adatok mennyisége fontosabb volt a teljesítménynél. Az ajánlás most az, hogy 1 TB deduplikálandó adathoz tartozzon (dedikáltan erre szánt) 5 GB memória. Ezen felül jelentős a plusz CPU igénye a deduplikációnak, ha a teljesítmény csökkenését el akarjuk kerülni. Több veszik a vámon, mint jön a réven.
Manapság a tárkapacitás még olcsóbb, mint a memória, így én (is) mindenkinek azt javaslom, hogy több kapacitást tegyen a gépbe deduplikáció helyett, meg több RAM-ot az ARC növelésre, és úgy lesz a legjobb a teljesítménye és a költséghatékonysága. Jól átgondolt pool tervezéssel általában simán "meg lehet takarítani" a deduplikálással megtakarítani remélt tárterületet, a hibatűrés romlása nélkül.
Összefoglalásként annyit javaslok nem túl nagy ZFS rendszert építőknek, hogy minél több RAM legyen, és L2ARC meg SLOG nélkül használják azt. Ha valamire a HDD pool-nál nagyobb sebességű pool kell (átvitel és/vagy IOPS), akkor legyen csak SSD pool ilyen célra a rendszerben (és az legyen mirror vagy stipe+mirror, ne RaidZx). Ezen felül a megfelelő pool tervezéssel érhető el a kívánt cél (nagy throughput és/vagy magas IOPS) leginkább, szóval a tervezésnél kell körültekintőnek lenni (mennyi meghajtó lesz egy VDEV, mennyi és milyen VDEV kerül egy pool-ba, stb.). A pool tervezés alapok legalább ennyi betű lenne még, mint ez az írás...
Meg fontos még az ashift értéke a teljesítmény terén, ami az adott VDEV/pool-ban használt meghajtók szektorméretétől függ (512 byte esetén 9, 4096 byte esetén pedig 11 a helyes értéke). Egy pool-ban lehetőleg ne legyen több különböző szektor méretű eszköz. Ez fontos.
Ezen felül érdemes a recordsize-t a tárolt adathoz igazítani, ezzel sokat lehet a helykihasználáson (ZFS space overhead) és a teljesítményen is javítani. Ha nagy állományok kerülnek rá (pl. média tartalom), akkor nyugodtan lehet 1 MB a recordsize, ha pedig kis rekordokkal dolgozó rendszer (adatbázis), akkor akár xx kB-ig is le lehet menni (a ZFS a 4 kB-os egységekkel már nem igazán bánik gyorsan, így érdemes DB esetén lehetőség szerint inkább 8-16-32-64 kB rekordméretre állni). A recordsize dataset szintű paraméter, szóval nem kell az egész pool-nak kicsi vagy nagy rekord méretűnek lennie. Ezen felül tetszőlegesen változtatható futásidőben, annyi megkötéssel, hogy a már tárolt adatok rekord mérete nem változik, csak az újonnan az adott dataset-re írt adatok lesznek az új rekord mérettel tárolva.
Remélem ezzel a sok szövegeléssel sikerül valakinek segítenem kicsit.