Amikor megjelenik az OpenZFS új verziója, sok rendszergazda elgondolkodik azon, hogy érdemes-e most frissíteni, vagy megvárni, amíg leülepszik a por. OpenZFS 2.4 A kérdés még érdekesebb, mert Mélységes változásokkal jár a teljesítmény, az új felügyeleti eszközök, valamint a közösségi vita a kiadásra jelölt szoftverek éles rendszerekben való használatáról.
Az OpenZFS 2.4 általános jellemzői
Az OpenZFS 2.4-et a következő verzióként mutatják be: stabil és meglehetősen ambiciózus jellem A Linux és FreeBSD környezetekre egyaránt tervezett projekt már a végső címkézésekor hangsúlyozta, hogy a cél a fájlrendszer és a kötetkezelő érettségének további előmozdítása, miközben fenntartja a kompatibilitást a legújabb kernelekkel és garantálja az adatbiztonságot.
Ez a verzió számos olyan funkciót egyesít magában, amelyek fejlesztése a kezdetektől fogva folyamatban volt. Ráma 2.3 és annak közbenső módosításai: teljesítményjavítások a titkosítási rétegúj menedzsmenteszközök, mint például zfs átírásRugalmasabb kvótakezelési lehetőségek, valamint belső változtatások, amelyek célja a fragmentáció csökkentése, a deduplikáció optimalizálása és az összetett szempontok, például a csoportos blokkkezelés vagy a problémás lemezekkel való viselkedés finomítása.
A közösség külön figyelmet fordított arra is, hogy integráció modern kernelekkelLinux alatt a támogatás a 4.18-as verziótól a legújabb LTS ágakig van deklarálva (beleértve a 6.18-as kernelt a 2.4-es stabil kiadás idején), míg a FreeBSD-ben a 13.3-as verziótól kezdődő verziók lefedettek, beleértve a 14.0-s és az újabb, előkészítés alatt álló ágakat, például a 15.0-s verziót is.
Platformtámogatás és kernel kompatibilitás az OpenZFS 2.4-gyel
Az OpenZFS 2.4 egyik pillére a széles platformkompatibilitásSok rendszergazda számára ez kulcsfontosságú, mivel lehetővé teszi számukra az operációs rendszer verzióinak frissítését a várt ZFS-funkciók elvesztése nélkül.
Linux oldalon az OpenZFS 2.4 a 4.18-as verziótól a sorozatig terjedő kernelekkel való kompatibilitást jelzi. 6.18 stabilEz mindent lefed a konzervatív vállalati disztribúcióktól kezdve a legújabb kernellel naprakészen futó, rendkívül naprakész környezetekig. A kettő között helyezkedik el a gyakori kiadások teljes spektruma: a szervereken használt LTS verziók, az egyedi kernelek, valamint a CentOS Streamhez vagy hasonló projektekhez hasonló verziók.
A FreeBSD új verziója a következőket támogatja: FreeBSD 13.3 Mostantól, beleértve a 14.0-s és a már a láthatáron lévő újabb verziókat, mint például a hamarosan megjelenő 15.0. Ez a széles választék biztosítja, hogy mind a már éles környezetben futó rendszerek, mind a következő generációs telepítések továbbra is használhatják az OpenZFS-t furcsa javítások vagy egyedi megoldások nélkül.
E kompatibilitás mögött egy folyamatos erőfeszítés rejlik, amely már a sorozatban is megmutatkozott. OpenZFS 2.3.xA korábbi frissítések, mint például a 2.3.4, kiterjesztették a kernel támogatását a 6.16-os verzióig, és összevonták a korábbi RC-kben megjelenő javításokat. Az OpenZFS 2.4 ott folytatja, ahol abbahagyta, és egy lépéssel tovább megy, igazodva a legújabb kernelekhez, és javítva azok élményét, akik viszonylag gyakran frissítik az alapvermüket.
Kvóták és új tárhelykezelési lehetőségek
A rendszergazda számára a legpraktikusabb új funkciók közé tartoznak a rendszer fejlesztései. előre meghatározott kvótákAz OpenZFS 2.4 bevezeti a felhasználók, csoportok és projektek alapértelmezett kvótáinak meghatározásának lehetőségét, így a tárhelyfelhasználás egységesebben szabályozható anélkül, hogy minden egyes esetet manuálisan kellene konfigurálni.
Ez a funkció lehetővé teszi például egy beállítást alapdíj minden felhasználó számára amelyek egy adott adatkészletben jönnek létre, vagy olyan projektkorlátok beállítására, amelyek automatikusan érvényesülnek új erőforrások lefoglalásakor. Ez egy nagyon hasznos eszköz többfelhasználós környezetekben, tárhelyszolgáltatásokban, laboratóriumokban és minden olyan forgatókönyvben, ahol meg szeretné akadályozni, hogy egy tévedés miatt a teljes erőforráskészlet megteljen.
Az alapértelmezett kvóták támogatása nem helyettesíti a meglévő specifikus kvótákat, hanem kiegészíti azokat. A rendszergazda meghatározhat egy globális politika majd finomítsa kivételekkel bizonyos felhasználók vagy csoportok számára, akiknek több (vagy kevesebb) helyre van szükségük. Mindezt a standard ZFS eszközökkel kezelheti, megtartva a már ismerős tulajdonságmodellt.
Közvetlen I/O, gyorsítótár nélküli I/O és rosszul igazított írási viselkedés
Teljesítmény szempontjából az OpenZFS 2.4 nagyon érdekes változást hoz a ... kezelésében. közvetlen bemenet/kimenetEddig a közvetlen I/O használata bizonyos helyzetekben ütközhetett az írási igazítással, és szuboptimális kódútvonalakat eredményezhetett. Az új verzió egy olyan mechanizmust vezet be, amely lehetővé teszi, hogy amikor a közvetlen I/O nem valósítható meg ideálisan, alternatív módot használjon a rendszer. könnyű, gyorsítótár nélküli I/O kifejezetten ilyen típusú forgatókönyvekhez tervezve.
Mit jelent ez a gyakorlatban? Hogy azok az írások, amelyek nem illeszkednek jól az elvárt irányzatokhoz, megszűnnek patológiás esetnek lenni, és ehelyett egy… optimalizált útvonal a ZFS-en belül. Csökken a többletterhelés, elkerülhetők bizonyos szűk keresztmetszetek, és kiszámíthatóbb viselkedés érhető el, különösen olyan környezetekben, ahol a közvetlen I/O-t használó alkalmazások együtt léteznek olyanokkal, amelyek nem.
Ez a változás különösen hasznos igényes munkaterhelések esetén, ahol a cél a következő: kihozni a teljesítményből tárolás a ZFS által kínált integritási garanciák feláldozása nélkül. Egy speciálisan tervezett tartalék megoldással az OpenZFS jobban megfelel számos olyan alkalmazás valóságának, amelyek nem mindig tartják be a műveletek ideális összehangolását.
Egységes allokációs szabályozás és fragmentációcsökkentés az OpenZFS 2.4-ben
Az OpenZFS 2.4-gyel járó másik jelentős változás egy új algoritmus bevezetése a következőkhöz: egységes elosztási szabályozásE név mögött egy mechanizmus rejlik, amelynek célja a virtuális eszközök (vdev-ek) fragmentációjának csökkentése és az írási műveletek elosztásának javítása, amikor a rendszer nyomás alatt van.
Eddig a nagy terhelésű helyzetekben a blokkok kiosztása olyan eloszlási mintákat eredményezhetett, amelyek idővel a a vdev fragmentációjaAz egységes algoritmus célja az allokációs arány harmonizálása, hogy a pool rendezettebb struktúrát tartson fenn, és a teljesítménybeli hátrányok csökkenjenek, amikor a hely fogyni kezd, vagy amikor a blokkméretek keveréke nagyon változatos.
Az ilyen típusú változtatások kevésbé észrevehetők, mint egy új parancs, de nagyon értékesek hosszú távú telepítéseknél, ahol egy készlet növekszik, újraegyensúlyozzák, új virtuális fejlesztői környezeteket (vdev-ket) adnak hozzá, és karbantartási műveleteket végeznek éveken keresztül. Az allokációvezérlés javításával az OpenZFS 2.4 segít fenntartani stabilabb viselkedés az idő múlásávalmég akkor is, ha a rendszert intenzíven használják.
Titkosítási fejlesztések az AVX2 és az AES-GCM segítségével
Biztonság és teljesítmény szempontjából az OpenZFS 2.4 számos optimalizálást tartalmaz a következők használatában: AVX2 AES-GCM-hezEgyszerűbben fogalmazva: a titkosítás implementációját finomították, hogy jobban kihasználják a modern processzorok képességeit, amelyek rendelkeznek ezekkel a fejlett vektoros utasításokkal.
Az eredmény gyorsabb titkosítás a kriptográfiai garanciák feláldozása nélkül, ami különösen észrevehető nagy mennyiségű titkosított adatot kezelő rendszerekben, vagy olyan környezetekben, ahol számos egyidejű műveletet hajtanak végre védett adatkészleteken. csökkentse a CPU terhelését A titkosítással társítva több kérés kezelhető, vagy több erőforrás fordítható más rendszerfeladatokra.
A gyakorlatban az adminisztrátorok továbbra is támaszkodhatnak a következő funkciókra: ZFS natív titkosítás hogy az érzékeny adatokat a korábbi generációk jelentős teljesítménybeli hatása nélkül védje. A titkosítás nem válik „ingyenessé”, de kezelhetőbbé válik olyan munkaterhelések alatt, ahol korábban egyértelmű szűk keresztmetszetet jelentett.
ZIL speciális vdev-ekben és fejlesztések speciális_kis_blokkokban
Az OpenZFS 2.4 új funkciókat is kínál a következők tekintetében: speciális vdev-ek, azok az eszközök, amelyeket bizonyos típusú adatok (például metaadatok, kis blokkok vagy deduplikációs táblázatok) gyorsabb adathordozón, általában SSD-n vagy NVMe-en történő tárolására terveztek.
Egyrészt most már lehetővé válik a ZIL (ZFS szándéknapló) Amikor elérhető, dedikált vdev-eken tárolja. Ez megkönnyíti a szinkron írások koncentrálását alacsony késleltetésű eszközökre, javítva a szinkronizálás-intenzív műveletekre támaszkodó alkalmazások, például az adatbázisok vagy az erős adatmegőrzéssel rendelkező üzenetküldő rendszerek válaszidejét.
Másrészt a tulajdonság viselkedése kibővül special_small_blocks így ZVOL írások Speciális vdev-ekbe is kerülhetnek, nem csak bizonyos szokásos fájlblokkokba. Továbbá enyhítették azt a korlátozást, hogy az értéknek kettő hatványának kell lennie, így a rendszergazda a tényleges munkaterheléséhez igazított finomabb méreteket választhat ahelyett, hogy merev beállításokra korlátozódna.
Ezek a fejlesztések együttesen lehetővé teszik olyan tárolási architektúrák tervezését, ahol a legfontosabb adatok A metaadatok, kis blokkok, ZIL-ek, deduplikációs táblázatok stb. gyorsabb adathordozókon tárolódnak, míg az adatok nagy része olcsóbb lemezeken marad. Mindez sokkal nagyobb rugalmassággal jár annak meghatározásában, hogy mi tekinthető „kicsinek” és mi nem.
zfs rewrite és zfs rewrite -P: adatok hatékony áthelyezése
A 2.3-as sorozat már tartalmazta az utóbbi idők egyik legszembetűnőbb funkcióját: az alparancsnokságot. zfs átírásAz OpenZFS 2.4 egy lépéssel tovább viszi ezt az eszközt a variáns beépítésével. zfs rewrite -Pami új lehetőségeket kínál az adatok egy csoporton belüli áthelyezésekor.
A parancs zfs rewrite lehetővé teszi „átírni„Egy fájl vagy adathalmaz tartalmát a logikai jelentése megváltoztatása nélkül másolja, de fizikailag áthelyezi más, eltérő belső tulajdonságokkal rendelkező területekre. Ez lehetővé teszi az olyan módosításokat, mint a tömörítési algoritmus, az ellenőrzőösszeg típusa, a deduplikáció alkalmazása, a másolatok száma vagy akár az előnyben részesített eszköz, anélkül, hogy az adatokat felhasználói tárhelyre kellene másolni és újraírni.”
Ennek számos egyértelmű előnye van: csökkenti az I/O forgalmat a klasszikus „másolás és átnevezés” módszerhez képest, minimalizálja a gyorsítótárra gyakorolt hatást, és elkerüli a hosszú időtartamokat, amelyek alatt az adatok külső eszközökön keresztül mozgathatók. Továbbá, mivel a tartalomban nincs logikai változás, Az mtime nem változik sem a felhasználó szemszögéből látható más tulajdonságok, ami azt jelenti, hogy sok alkalmazás nincs is tudatában a műveletnek.
A választás zfs rewrite -P lehetőséget ad hozzá őrizd meg a logikus születési időpontot a blokkok lehetőség szerinti cseréjét, ami segít minimalizálni az inkrementális replikációs folyamatok méretét. Azáltal, hogy ezt az információt stabilan tartja, a későbbi küldési/fogadási műveletek jobban azonosíthatják, hogy mi változott valójában és mi nem, csökkentve ezzel a rendszerek között mozgatandó adatok mennyiségét.
Egy másik fontos előny, hogy az átírási folyamat védett tűzzárak normális, így párhuzamosan futtatható a valós munkaterhelésekkel anélkül, hogy indokolatlanul blokkolná a rendszert. Az adathalmazokban, amelyek sync=always Az előny még nagyobb, mivel az adatok logikai módosításának hiányában nem kell további írásokat végrehajtani a ZIL-ben, így elkerülhetők a szinkron műveletek során felmerülő többletköltségek.
Új kezelési lehetőségek az OpenZFS 2.4-ben: -a|–all, range scrub és BRT prefetch
Az OpenZFS 2.4 finomítja és bővíti a felügyeleti eszközök arzenálját számos nagyon hasznos lehetőséggel a mindennapi használatra. Ezek egyike a következő opció hozzáadása: -a|–mind olyan parancsokban, amelyek karbantartási feladatokat hajtanak végre a készleteken, például súrolást, vágást vagy inicializálást.
Ez az opció lehetővé teszi egy olyan művelet elindítását, amely hatással van a következőkre: minden importált medence mindezt egyszerre, ahelyett, hogy manuálisan kellene mindegyiken végigmenni. Ez nagyban leegyszerűsíti a dolgokat a több készletet kezelő szervereken, csökkentve az emberi hibákat és megkönnyítve az automatizálást.
Ezenkívül felmerült egy lehetőség egy zpool scrub korlátozott meghatározott időtartományok a lehetőségeken keresztül -S -EEz a funkció nagy értéket képvisel, ha csak egy olyan időszakot szeretne áttekinteni, amelyben problémák merülnek fel, vagy ha egy tisztítás költségét több részleges végrehajtásra szeretné elosztani, hogy ne befolyásolja túlságosan az összteljesítményt.
Egy másik fontos új funkció a következő hozzáadása: zpool prefetch -t brt előre betölteni a memóriába Blokk referenciatábla (blokk klónozási táblázat)Ez lehetővé teszi a korábbi verziókban bevezetett blokkklónozási funkció jobb kihasználását, csökkentve a késleltetést a funkcióban érintett belső struktúrák elérésekor.
Engedélyek, átnevezett eszközök, valamint fejlesztések a deduplikációhoz és a klónozás blokkolásához
A felhasználói élményt finomító apró, de jelentős fejlesztések között szerepel az OpenZFS 2.4 új jogosultságokkal bővült. küldés: titkosítottÚgy tervezték, hogy részletesebb szabályozást biztosítson a titkosított adatok küldésére jogosultak felett, és jól működik azokkal a csapatokkal, amelyekben elkülönülnek a felelősségi körök a pillanatképek kezelői, a replikációt kezelők és a titkosítási kulcsokhoz hozzáférő személyek között.
A hagyományos közműveket is átnevezték, mint például arc_summary y arcstat, amelyek aztán ismertté válnak zarcsummary y zarcstatEz a módosítás segít elkerülni a névütközéseket, és egyértelműbbé teszi, hogy ezek a ZFS-hez kapcsolódó eszközök, ami hasznos olyan rendszerekben, amelyek több, hasonló parancsokat tartalmazó komponenst tartalmaznak.
Belsőleg a 2.4-es sorozat felhalmozódik Új optimalizálások és javítások Ez mind a deduplikációra, mind a blokkklónozásra vonatkozik. Az adatszerkezeteket finomítják, a peremhelyzeteket korrigálják, és jobb hozzáférési mintákat keresnek, hogy a memóriára és a CPU-ra gyakorolt hatás kezelhetőbb legyen. Ezek a változások nem láthatók közvetlenül a felhasználó számára, de stabilabb viselkedést és kevesebb meglepetést eredményeznek összetett munkaterhelések esetén.
Csoportblokkok, ashift, lassú gyermek vdev-ek és speciális topológiák
Az OpenZFS 2.4 számos fejlesztést és hibajavítást is tartalmaz a korábbi verziókhoz képest. bandablokkokEz egy belső rendszerfunkció, amelyet a hagyományos módon nem elhelyezhető blokkok kezelésére terveztek. Bár a legtöbb felhasználó nem lép közvetlenül kapcsolatba velük, a kód ezen részében bekövetkező bármilyen hiba súlyos következményekkel járhat, így a számos javítás és optimalizálás jó hír a rendszer általános robusztussága szempontjából.
Ezzel párhuzamosan a következők kezelése: váltásAz a paraméter, amely meghatározza a minimális foglalási egységet az eszköz szektorainak fizikai méretével összhangban. A jobb eltolódáskezelés csökkenti annak lehetőségét, hogy a nagy szektorokkal rendelkező lemezekre a szükségesnél több adatot írjunk, és segít fenntartani az elfogadható teljesítményszintet a készlet élettartama alatt.
Egy másik érdekes új funkció, hogy a gyermek vdev-ek viselkedését a következőképpen lehet módosítani: rendellenesen lassú Ideiglenesen „beállíthatók” a rendszerbe. Ahelyett, hogy a teljes rendszer teljesítményét rontanák, egy időre le lehet őket venni a működésről, ami nagyon hasznos, ha a lemezek kezdenek meghibásodni, a meghajtók időszakos problémákkal küzdenek, vagy a környezetek inkonzisztens hardverekkel rendelkeznek.
Végül is, van nekik lazított topológiai korlátozások Speciális és deduplikációs VDEV-k esetén ez nagyobb rugalmasságot biztosít a fejlett konfigurációjú poolok tervezésekor. Ez lehetővé teszi a gyors eszközök jobb integrációját a metaadatokhoz, a deduplikált táblázatokhoz, a ZIL-ekhez és más érzékeny elemekhez anélkül, hogy túlságosan merev korlátozásokba ütköznénk az elrendezés definíciójában.
OpenZFS 2.3.4: Karbantartás, kezdeti zfs átírás és konszolidáció
Ahhoz, hogy teljes mértékben megértsük a 2.4-es érték által képviselt ugrást, érdemes egy gyors pillantást vetni a következőkre: OpenZFS 2.3.4, egy karbantartó verzió, amely röviddel azelőtt jelent meg, és lerakta az alapjait annak, amit később az új fő ágban konszolidáltak.
A 2.3.4-es verzió két hónappal a 2.3.3-as verzió után jelent meg, és nagyon erős hangsúlyt fektetett a következőkre: robusztusság és kompatibilitásKiterjesztette a Linux kernel támogatását a 6.16-os verzióig, a minimumot a 4.18-as verzión tartva, és megerősítette a FreeBSD-vel való kompatibilitást a 13.3-as verziótól kezdődően, beleértve a hamarosan megjelenő 15.0-s verziót is. Más szóval, már előkészítette az alapokat a modern alaprendszerekkel való együttélésre a stabilitás feláldozása nélkül.
Ez a konkrét áttekintés a parancs kezdeti verziójának debütálását jelentette. zfs rewritekifejezetten erre tervezve adatok áthelyezése logikai tartalmuk megváltoztatása nélkül és anélkül, hogy olyan nehézkesebb stratégiákhoz kellene folyamodni, mint a másolás/átnevezés vagy a küldés/fogadás adathalmaz-átnevezéssel. A cél egy olyan eszköz biztosítása volt, amely képes újraegyensúlyozni egy készletet a vdev-ek hozzáadása után, csökkenteni a véletlenszerűen írt fájlok töredezettségét, vagy új tárolási tulajdonságokat alkalmazni a meglévő adatokra.
A hagyományos alternatívákkal összehasonlítva, zfs rewrite Gyorsabb, mert elkerüli az adatok felhasználói térbe történő utazását. Az olyan adathalmazokban, amelyeknél sync=alwaysTovábbá javítja a teljesítményt, mert mivel az adatok logikailag nem módosulnak, nem történik további írás a ZIL-ben. Mindezt anélkül, hogy bármihez hozzá kellene nyúlni. mtime vagy más metaadatok látható az alkalmazások számára, ami minimalizálja a rajta futó szoftverekre gyakorolt hatást.
A 2.3.4-es verzió emellett különféle FreeBSD-specifikus beállításokTartalmazott csomagolási fejlesztéseket és egy sor kisebb javítást, amelyek a kód egyes szegleteit csiszolták. Nem egy olyan verzióról volt szó, amely áttörést hozna, hanem inkább a stabilitás finomhangolására szolgálna, mielőtt a 2.4-es ágra ugrana egy nagyobb csomag új funkcióval.
OpenZFS 2.4 RC1, RC2, RC4: tesztelés, visszajelzés és közösségi beszélgetés
Mielőtt a 2.4-es sorozatot stabilnak nyilvánították, a projekt többet is kiadott elengedni a jelölteket (RC1, RC2, RC4) azzal a céllal, hogy a haladó felhasználók és fejlesztők tesztelhessék őket és jelenthessék a problémákat. Ezek a kiadásra jelölt verziók gyakorlatilag az összes olyan funkciót tartalmazták, amelyet már megvitattunk: alapértelmezett kvóták, gyorsítótár nélküli I/O tartalék megoldásként, egységes allokációs szabályozás, titkosítási fejlesztések, ZIL speciális vdev-ekben, special_small_blocks kiterjesztések, új jogosultságok, eszközök átnevezése és még sok más.
Az RC1 és RC2 jegyzetek hangsúlyozták a közösség fontosságát Tesztelni fogom a buildeket és küldjön visszajelzést a GitHubon keresztül, beleértve a hivatkozási ághoz képesti változások egyszerű listázására szolgáló parancsokat is (a következő kombinációkkal: git cherry (a zfs-2.3-release összehasonlítása a különböző RC-kkel). Az üzenet világos volt: a cél a kód valós környezetben való tesztelése volt, mielőtt „stabilnak” neveznénk.
Egy adott RC megjelenése azonban (például 2.4.0-RC4A .NET-keretrendszer (RF) beépítése a FreeBSD RELEASE jelölésű verziójába, például a 15.0-ba némi felháborodást keltett. Néhány felhasználó azon tűnődött, hogy miért döntöttek a beépítése mellett. OpenZFS kiadásra jelölt az operációs rendszer egy stabilnak tekintett verziójában, ahelyett, hogy egy korábbi, már létrehozott ághoz folyamodnánk. Ez a választás némi elégedetlenséget váltott ki azok körében, akik azt szeretnék, hogy az adataik tárolására szolgáló fájlrendszer szigorúan a végleges verziókon alapuljon.
A kétségek a döntés tartósságával kapcsolatban merültek fel: ha valaki telepíti a FreeBSD 15.0-t az OpenZFS 2.4.0-RC4-gyel, majd nem követi a -CURRENT ágat, fennáll a veszélye annak, hogy hónapokig „beragad” egy kiadásra jelölt verzióval, amíg egy kisebb revízió vagy a sorozat egy új pontja meg nem érkezik. Az is aggodalomra adott okot, hogy a jövőbeli kiadások, mint például 15.1 egy másik RC-t integrálna (például egy hipotetikus 2.4.1-RC3-at) egy végleges verzió helyett.
E vita mögött különböző értelmezések húzódnak meg, hogy mi is „kiadásra jelölt„Egy olyan érzékeny kontextusban, mint egy fájlrendszer. Egyesek számára a Release Candidate (RC) gyakorlatilag egy stabil verzió, amely csak kisebb módosításokat igényel. Mások számára azonban ez egy olyan kód, amelyet nem szabad RELEASE jelölésű rendszer alapjául használni, és azoknak kell fenntartani, akik szorosan követik a fejlesztői ágakat.”
Mindenesetre az RK-k teljesítették küldetésüket tesztelésEzek a fejlesztések lehetővé tették a hibák észlelését, a részletek módosítását, és sokkal magabiztosabb érkezést a „2.4 stabil” kiadáshoz. Azok, akik mindenekelőtt a biztonságot helyezik előtérbe, továbbra is választhatják a korábbi ágak, például a 2.3.x verziók használatát, amíg a 2.4-et kellően érettnek nem ítélik éles környezetben.
Az OpenZFS 2.4 minden hozadéka a 2.3-as sorozattal és annak karbantartási frissítéseivel elért robusztusságon alapul, amely ötvözi a kernel kompatibilitási fejlesztéseket, az olyan új eszközöket, mint a zfs átírásA kiadás módosításokat tartalmaz a deduplikáció és a blokkklónozás terén, titkosítási optimalizálásokat, belső változtatásokat a gang blokkokban és az asiftben, valamint számos új kezelési lehetőséget. Bár némi vita merült fel a kiadásra jelölt verziók használatával kapcsolatban bizonyos operációs rendszereken, a stabil 2.4-es verzió jelentős előrelépést kínál azok számára, akik többet szeretnének kihozni a ZFS-ből Linux és FreeBSD rendszereken anélkül, hogy feláldoznák a bevett integritási és rugalmassági garanciákat.
