ZFS - ZFS

ZFS

Fejlesztő	Sun Microsystems ( az Oracle Corporation felvásárolta 2009 -ben)
Beírták	C , C ++
OS család	Unix ( System V Release 4 )
Működő állapot	Jelenlegi
Forrásmodell	Vegyes nyílt forráskódú / zárt forráskódú
Első kiadás	2006. június ; 15 évvel ezelőtt Solaris 10 6/06 ("U2") ( 2006-06 )
Legutolsó kiadás	11.4 / 2018. augusztus 28 .; 3 évvel ezelőtt ( 2018-08-28 )
Marketing cél	Munkaállomás , szerver
Platformok	SPARC , x86-64 , IA-32 (kivéve Solaris 11), PowerPC (csak Solaris 2.5.1)
Engedély	Különféle
Hivatalos honlapján	www .oracle .com /solaris

OpenZFS

Első kiadás	2006 és 2010 között különböző rendszerekhez hordozva. Az OpenSolaris 2010. augusztusi villája ; 11 évvel ezelőtt ( 2010-08 )
Stabil kiadás	2.0.5 / 2021. június 23 .; 3hónappal ezelőtt ( 2021-06-23 )
Adattár	GitHub .com / openzfs / ZFS
Beírták	C
Operációs rendszer	OpenSolaris , illumos disztribúciók, OpenIndiana , FreeBSD , Mac OS X Server 10.5 (csak olvasható támogatás), NetBSD , Linux harmadik féltől származó kernelmodulon keresztül ("ZFS Linuxon") vagy ZFS- FUSE , OSv
Engedély	nyílt forráskódú CDDL
Weboldal	openzfs .org

A ZFS (korábban: Zettabyte fájlrendszer) egyesíti a fájlrendszert a kötetkezelővel . A Sun Microsystems Solaris operációs rendszer részeként indult 2001 -ben. A Solaris nagy részeit - köztük a ZFS -t - 2005 -től körülbelül 5 évig nyílt forráskódú licenc alatt , OpenSolaris néven publikálták , mielőtt zárt forrású licenc alá helyezték, amikor az Oracle Corporation felvásárolta Nap 2009/2010. 2005-ben az 2010-ben a nyílt forráskódú változata ZFS-t portolták a Linux , Mac OS X (folytatta MacZFS ) és FreeBSD . 2010-ben a illumos projekttel villás egy újabb verziója OpenSolaris, hogy folytassa a fejlődést a nyílt forráskódú projekt, beleértve a ZFS. 2013 -ban az OpenZFS -t azért hozták létre, hogy koordinálja a nyílt forráskódú ZFS fejlesztését. Az OpenZFS karbantartja és kezeli az alapvető ZFS -kódot, míg a ZFS -t használó szervezetek fenntartják azokat a specifikus kódokat és érvényesítési folyamatokat, amelyek szükségesek ahhoz, hogy a ZFS rendszerébe integrálódjon. Az OpenZFS-t széles körben használják a Unix-szerű rendszerekben.

Áttekintés

A tárolt adatok kezelése általában két aspektusból áll: egy vagy több blokktároló eszköz , például merevlemezek és SD -kártyák fizikai kötetkezelése, és azok logikai blokkeszközökké szervezése az operációs rendszer szerint (gyakran kötetkezelővel , RAID -vezérlővel) , tömbkezelő vagy megfelelő eszközillesztő ), valamint az ezeken a logikai blokkeszközökön ( fájlrendszer vagy egyéb adattároló) tárolt adatok és fájlok kezelése .

Példa: egy RAID tömb 2 merevlemez és SSD gyorsítótár-lemez által vezérelt Intel RST rendszer része a chipset és firmware épített egy asztali számítógép. A Windows felhasználó ezt egyetlen kötetnek tekinti, amely adatainak NTFS formátumú meghajtóját tartalmazza, és az NTFS nem feltétlenül ismeri az esetlegesen szükséges manipulációkat (például olvasást a gyorsítótárból/írást a gyorsítótárba vagy a RAID tömb újjáépítését, ha lemez meghibásodik). Az egyes eszközök kezelése és egyetlen eszközként történő megjelenítése különbözik az ezen a nyilvánvaló eszközön tárolt fájlok kezelésétől.

A ZFS szokatlan, mert a legtöbb más tárolórendszerrel ellentétben egyesíti ezeket a szerepeket, és egyben kötetkezelőként és fájlrendszerként is működik . Ezért teljes ismeretekkel rendelkezik mind a fizikai lemezekről és kötetekről (beleértve azok állapotát és állapotát, kötetek logikai elrendezését), mind a rajtuk tárolt fájlokról. ZFS célja annak biztosítása, (feltéve, hogy megfelelő hardver ), amely a tárolt adatok lemezek nem vész miatt a fizikai hibák vagy misprocessing a hardver vagy az operációs rendszer , vagy bit rothadás események és adatok a korrupció , ami megtörténhet az idő múlásával, és annak teljes ellenőrzése a tárolórendszert annak biztosítására használják, hogy minden lépést, függetlenül attól, hogy fájlkezeléssel vagy lemezkezeléssel kapcsolatos -e , ellenőrzik, megerősítik, szükség esetén korrigálják és optimalizálják, oly módon, hogy a tárolóvezérlő kártyák és a különálló kötet- és fájlkezelők nem tudják elérni.

A ZFS tartalmaz egy mechanizmust az adatkészletek és a pool szintű pillanatfelvételek készítéséhez és a replikációhoz , beleértve a pillanatfelvételek klónozását is, amelyet a FreeBSD dokumentációja az egyik "legerősebb szolgáltatásnak" nevez, és olyan funkciókkal rendelkezik, amelyek "még más pillanatkép funkcióval rendelkező fájlrendszerekben is hiányoznak". Nagyon sok pillanatfelvétel készíthető a teljesítmény romlása nélkül, lehetővé téve a pillanatfelvételek használatát a kockázatos rendszerműveletek és szoftvercserék előtt, vagy egy teljes éles ("élő") fájlrendszer teljes felvételét óránként többször, hogy csökkenti a felhasználói hiba vagy rosszindulatú tevékenység miatti adatvesztést. A pillanatképek "élőben" visszagörgethetők, vagy megtekinthetők a korábbi fájlrendszer -állapotok, még nagyon nagy fájlrendszereken is, ami megtakarítást eredményez a hivatalos mentési és visszaállítási folyamatokhoz képest. A pillanatképek klónozhatók új független fájlrendszerek létrehozására is. Rendelkezésre áll egy készletszintű pillanatkép (az úgynevezett "ellenőrzőpont"), amely lehetővé teszi azoknak a műveleteknek a visszavonását, amelyek hatással lehetnek a teljes készlet szerkezetére, vagy amelyek egész adatkészletet adnak hozzá vagy távolítanak el.

Történelem

Sun Microsystems (2010 -ig)

1987 -ben az AT&T Corporation és a Sun bejelentette, hogy együttműködnek egy olyan projektben, amely egyesíti a piacon akkoriban legnépszerűbb Unix változatokat: a Berkeley Software Distribution , a UNIX System V és a Xenix . Ez lett a Unix System V Release 4 (SVR4). A projekt Solaris néven jelent meg , amely a SunOS 4 utódja lett (bár a SunOS 4.1. X mikro kiadásokat visszamenőleg Solaris 1 névre keresztelték ).

A ZFS -t a Sun csapata tervezte és valósította meg Jeff Bonwick , Bill Moore és Matthew Ahrens vezetésével . 2004. szeptember 14 -én jelentették be, de a fejlesztés 2001 -ben kezdődött. A ZFS forráskódját 2005. október 31 -én integrálták a Solaris fejlesztés fő törzsébe, és 2005. november 16 -án kiadták a fejlesztőknek az OpenSolaris 27. verziójának részeként. 2006 júniusában a Sun bejelentette, hogy a ZFS bekerült a Solaris 10 main 6/06 frissítésébe .

A Solaris történelmileg saját fejlesztésű szoftver . A Sun Microsystems a nyílt forráskódú szoftverek erős támogatója volt . 2005 júniusában a Sun kiadta a legtöbb kódbázist a CDDL licenc alapján, és megalapította az OpenSolaris nyílt forráskódú projektet. A Sun a nyílt forráskódú szoftverek korai támogatója volt , és az OpenSolaris segítségével a Sun fejlesztői és felhasználói közösséget akart építeni a szoftver köré. A Solaris 10 6/06 ("U2") dokumentumban a Sun hozzáadta a ZFS fájlrendszert. A következő 5 évben (2006-2010), a Sun ZFS gyakran frissített az új funkciók, és a ZFS-t portolták a Linux , Mac OS X (folytatta MacZFS ) és FreeBSD alatt ez a nyílt forráskódú licenc.

A név egy helyen azt mondta, hogy "Zettabyte File System", de 2006 -ra a nevet már nem tekintették rövidítésnek. Egy ZFS fájlrendszer akár 256 quadrillion zettabytes (ZB) tárolására képes .

2007 szeptemberében a NetApp beperelte a Sun -t, azt állítva, hogy a ZFS megsértette a NetApp néhány szabadalmát az Write Anywhere File Layout -ban . A Sun ugyanezen év októberében perelte az ellenkezőjét. A perek 2010 -ben fejeződtek be egy ismeretlen rendezéssel.

Későbbi fejlesztés

A ZFS hordozott verziói 2005-ben kezdtek megjelenni. Miután az Oracle 2010-ben felvásárolta az Oracle- t, az Oracle ZFS verziója zárt forrásúvá vált, és a nyílt forráskódú verziók fejlesztése önállóan zajlott , az OpenZFS koordinálta 2013-tól.

Jellemzők

Összefoglaló

Példák a ZFS -re jellemző szolgáltatásokra:

• Hosszú távú adatok tárolására és korlátlan méretarányú adattárolóméretekre tervezték, nulla adatvesztéssel és magas konfigurálhatósággal.
• Az összes adat és metaadat hierarchikus ellenőrző összegezése , annak biztosítása, hogy a teljes tárolórendszer használat közben ellenőrizhető legyen, és megerősítésre kerüljön, hogy helyesen tárolt, vagy orvosolható, ha sérült. Ellenőrzőösszegek tárolja a blokk szülő blokk , hanem a blokk is. Ez ellentétben áll sok olyan fájlrendszerrel, ahol az ellenőrző összegeket (ha megtartják) az adatokkal együtt tárolják, így ha az adatok elvesznek vagy megsérülnek, az ellenőrző összeg is elveszik vagy helytelen.
• Tárolhat egy felhasználó által meghatározott számú adat- vagy metaadat-másolatot vagy kiválasztott adattípust, hogy javítsa a fontos fájlok és struktúrák adatkorrupcióból való helyreállítási képességét.
• A fájlrendszer és az adatok legutóbbi módosításainak automatikus visszavonása, bizonyos körülmények között, hiba vagy következetlenség esetén.
• Az adatok következetlenségeinek automatikus és (általában) csendes öngyógyítása és az írási hiba észlelésekor minden olyan hiba esetén, ahol az adatok rekonstruálhatók. Az adatok a következők mindegyikével rekonstruálhatók: az egyes blokkok szülőblokkjában tárolt hibafelismerő és -javító ellenőrző összegek; a lemezen tárolt adatok több példánya (beleértve az ellenőrző összegeket is); a SLOG -on (ZIL) naplózott írási szándékok olyan írásokhoz, amelyeknek meg kellett volna történniük, de nem történtek meg (áramszünet után); paritásadatok a RAID/RAID-Z lemezekről és kötetekről; tükrözött lemezekről és kötetekről származó adatok másolatai.
• A szabványos RAID-szintek és a további ZFS RAID-elrendezések (" RAID-Z ") natív kezelése . A RAID-Z a hatékonyság érdekében csak a szükséges lemezeken szétválasztja az adatokat (sok RAID-rendszer válogatás nélkül csíkos az összes eszközön), és az ellenőrző összegzés lehetővé teszi az inkonzisztens vagy sérült adatok újjáépítését a hibás blokkokra;
• A többszintű tároló- és gyorsítótárazási eszközök natív kezelése, amely általában kötettel kapcsolatos feladat. Mivel a ZFS a fájlrendszert is megérti, a fájlokkal kapcsolatos ismeretek felhasználásával tájékoztathatja, integrálhatja és optimalizálhatja a többszintű tárolási kezelést, amit egy különálló eszköz nem tud;
• A pillanatképek natív kezelése és a biztonsági mentés/ replikáció, amelyet a kötet és a fájlkezelés integrálásával lehet hatékonyabbá tenni. A megfelelő eszközök alacsony szinten állnak rendelkezésre, és használatukhoz külső parancsfájlok és szoftverek szükségesek.
• Natív adattömörítés és deduplikáció , bár ez utóbbit nagyrészt RAM -ban kezelik, és memóriaéhes.
• A RAID tömbök hatékony újjáépítése - a RAID vezérlőnek gyakran újjá kell építenie egy teljes lemezt, de a ZFS a lemez- és fájlismeretek kombinálásával korlátozhatja az újjáépítést a ténylegesen hiányzó vagy sérült adatokra, ami jelentősen felgyorsítja az újjáépítést;
• Nem érinti a RAID hardverváltozás, amely sok más rendszert érint. Sok rendszerben, ha az önálló RAID-hardver, például a RAID-kártya meghibásodik, vagy az adatokat egy másik RAID-rendszerbe helyezi át, a fájlrendszerből hiányoznak azok az információk, amelyek az eredeti RAID-hardveren voltak, ami a RAID-adatok kezeléséhez szükséges. sor. Ez teljes adatvesztéshez vezethet, hacsak közel azonos hardvert nem lehet beszerezni és "lépcsőfokként" használni. Mivel a ZFS maga kezeli a RAID-t, a ZFS-készlet áttelepíthető más hardverre, vagy az operációs rendszer újratelepíthető, és a RAID-Z struktúrákat és adatokat a ZFS újra felismeri és azonnal hozzáférheti.
• Képesség azonosítani azokat az adatokat, amelyeket a gyorsítótárban találtak volna, de a közelmúltban elvetették; ez lehetővé teszi a ZFS számára, hogy a későbbi felhasználás fényében újraértékelje gyorsítótárazási döntéseit, és elősegíti a nagyon gyors gyorsítótár-találatok szintjét (a ZFS-gyorsítótár találati aránya általában 80%felett van);
• Alternatív gyorsítótárazási stratégiák használhatók olyan adatokhoz, amelyek egyébként késést okoznának az adatkezelésben. Például a szinkron írások, amelyek képesek lelassítani a tárolórendszert, átalakíthatók aszinkron írásokká, ha egy gyors, külön tárolóeszközre írják, amelyet SLOG -nak (más néven ZIL - ZFS szándéknaplónak) neveznek.
• Nagyon jól hangolható - sok belső paraméter konfigurálható az optimális működés érdekében.
• Használható nagy rendelkezésre állású klaszterekhez és számítástechnikához, bár nem teljesen erre a használatra tervezték.

Az adatok integritása

Az egyik fő jellemző, amely megkülönbözteti a ZFS -t a többi fájlrendszertől, az, hogy az adatok integritására összpontosítva úgy tervezték, hogy megvédi a felhasználó adatait a lemezen a csendes adatvesztéstől , amelyet az adatromlás , az áramlökések ( feszültségcsúcsok ), a lemez firmware -i hibái okoznak , a fantom írások (az előző írás nem jutott lemezre), rosszul irányított olvasás/írás (a lemez rossz blokkhoz fér hozzá), DMA paritáshibák a tömb és a szerver memóriája között vagy az illesztőprogramból (mivel az ellenőrző összeg ellenőrzi a tömbön belüli adatokat), illesztőprogram -hibák (az adatok rossz pufferbe kerülnek a kernelben), véletlen felülírások (például élő fájlrendszerre váltás) stb.

Egy 1999-es tanulmány kimutatta, hogy az akkoriban nagy jelentőségű és széles körben elterjedt fájlrendszerek (például UFS , Ext , XFS , JFS vagy NTFS ), sem a hardveres RAID (amelynek bizonyos problémái vannak az adatintegritással ) nem nyújt elegendő védelmet az adatkorrupciós problémák ellen. Az első kutatások azt mutatják, hogy a ZFS jobban védi az adatokat, mint a korábbi erőfeszítések. Ezenkívül gyorsabb, mint az UFS, és helyettesítőnek tekinthető.

A ZFS-en belül az adatok integritása Fletcher-alapú ellenőrző összeg vagy SHA-256 kivonat használatával érhető el a fájlrendszer fájában. Minden adatblokk ellenőrző összeget kap, és az ellenőrző összeg értékét az adott blokkra mutató mutatóba menti - nem pedig a tényleges blokkra. Ezt követően a mondatmutató ellenőrző összege lesz, az érték pedig a mutatónál kerül mentésre . Ez az ellenőrző összegzés a fájlrendszer adathierarchiájában egészen a gyökércsomópontig folytatódik, amely szintén ellenőrző összeget kap, így létrehozva egy Merkle fát . A repülés közbeni adatok sérülése vagy fantom olvasása/írása (az adatok helyesen írva/olvasva az ellenőrző összegeket, de valójában hibásak) a legtöbb fájlrendszer számára nem észlelhetők, mivel tárolják az ellenőrző összeget az adatokkal. A ZFS minden blokk ellenőrző összegét a szülőblokk-mutatóban tárolja, így a teljes készlet önellenőrzi magát.

Egy blokk elérésekor, függetlenül attól, hogy adat vagy meta-adat, ellenőrző összegét kiszámítják, és összehasonlítják a tárolt ellenőrző összeg értékével. Ha az ellenőrző összegek megegyeznek, akkor az adatokat továbbítják a programozási kötegen a folyamatnak, amely kérte; ha az értékek nem egyeznek, akkor a ZFS meg tudja gyógyítani az adatokat, ha a tárolókészlet adatredundanciát biztosít (például belső tükrözés esetén ), feltéve, hogy az adatok másolata sértetlen és megfelelő ellenőrző összegekkel. Opcionálisan lehetőség van további pool-redundancia biztosítására a másolatok = 2 (vagy másolatok = 3 vagy több) megadásával , ami azt jelenti, hogy az adatok kétszer (vagy háromszor) kerülnek tárolásra a lemezen, gyakorlatilag megfelezve (vagy másolatok esetén = 3 , harmadára csökkentve) a lemez tárolókapacitását. Ezenkívül a ZFS által a készlet kezelésére használt bizonyos típusú adatok alapértelmezés szerint többször kerülnek tárolásra a biztonság érdekében, még az alapértelmezett másolatok = 1 beállítás mellett is.

Ha a sérült adatok más példányai is léteznek, vagy az ellenőrző összegekből és paritásadatokból rekonstruálhatók , a ZFS az adatok egy másolatát használja fel (vagy RAID -helyreállítási mechanizmuson keresztül hozza létre újra), és újraszámítja az ellenőrző összeget - ideális esetben az eredeti várható érték. Ha az adatok átmennek ezen integritás-ellenőrzésen, akkor a rendszer frissíteni tudja az összes hibás példányt ismert jó adatokkal, és a redundancia helyreáll.

A memóriában tárolt adatok-például az ARC-ben tárolt adatok-következetességét alapértelmezés szerint nem ellenőrzik, mivel a ZFS várhatóan vállalati minőségű hardveren fog futni, hibajavító RAM-mal , de a memóriában lévő adatok ellenőrzése megvan és lehetséges. engedélyezett a "hibakeresési zászlók" használatával.

RAID ("RAID-Z")

Ahhoz, hogy a ZFS garantálni tudja az adatok integritását, több példányra van szüksége az adatokból, általában több lemezen. Ezt általában RAID vezérlő vagy úgynevezett "lágy" RAID ( fájlrendszerbe épített ) használatával érik el .

A hardveres RAID vezérlők elkerülése

Míg a ZFS képes hardveres RAID -eszközökkel dolgozni , a ZFS általában hatékonyabban és nagyobb adatvédelemmel fog működni, ha nyers hozzáféréssel rendelkezik az összes tárolóeszközhöz. A ZFS a lemezen alapul, hogy őszinte képet kapjon arról, hogy az adatok mikor vannak biztonságosan írva, és számos algoritmussal rendelkezik, amelyek optimalizálják a gyorsítótárazás , a gyorsítótár -öblítés és a lemezkezelés használatát.

A rendszerhez hardver, firmware, egyéb "puha" RAID vagy a ZFS-lemez- I/O útvonalat módosító vezérlő segítségével csatlakoztatott lemezek befolyásolják a ZFS teljesítményét és az adatok integritását. Ha egy harmadik féltől származó eszköz gyorsítótárazást hajt végre, vagy egyetlen rendszerként jeleníti meg a meghajtókat a ZFS alacsony szintű nézete nélkül , sokkal nagyobb az esélye annak, hogy a rendszer kevésbé fog optimálisan teljesíteni, és a ZFS kevésbé valószínű, hogy megakadályozza a hibákat, lassabban gyógyuljon meg a hibákból, vagy írási hiba miatt veszítsen adatokat. Például, ha hardveres RAID kártyát használ, előfordulhat, hogy a ZFS nem tudja: meghatározni a lemezek állapotát; határozza meg, hogy a RAID tömb leromlott vagy újjáépül; minden adatkorrupció felderítése; az adatok optimális elhelyezése a lemezeken; szelektív javításokat végezni; ellenőrizheti, hogy a javítások kiegyensúlyozottak -e a folyamatos használattal; vagy olyan javításokat végezzen, amelyeket a ZFS általában elvállalhat. A hardveres RAID kártya zavarja a ZFS algoritmusait. A RAID vezérlők rendszerint vezérlőfüggő adatokat is hozzáadnak a meghajtókhoz, ami megakadályozza, hogy a szoftver RAID hozzáférjen a felhasználói adatokhoz. Hardveres RAID -vezérlő meghibásodása esetén lehetséges, hogy az adatokat egy másik kompatibilis vezérlővel is ki lehet olvasni, de ez nem mindig lehetséges, és előfordulhat, hogy a csere nem áll rendelkezésre. Előfordulhat, hogy az alternatív hardveres RAID -vezérlők nem értik az eredeti gyártó egyedi adatait, amelyek a tömb kezeléséhez és visszaállításához szükségesek.

Ellentétben a legtöbb más rendszerrel, ahol a RAID -kártyák vagy hasonló hardverek leterhelhetik az erőforrásokat és a feldolgozást a teljesítmény és a megbízhatóság növelése érdekében, a ZFS használata esetén erősen ajánlott, hogy ne használja ezeket a módszereket , mivel általában csökkentik a rendszer teljesítményét és megbízhatóságát.

Ha a lemezeket RAID -en vagy más vezérlőn keresztül kell csatlakoztatni, ajánlott minimálisra csökkenteni a vezérlőben végzett feldolgozást egy sima HBA (host adapter) , egy egyszerű fanout kártya használatával, vagy konfigurálni a kártyát JBOD módban (pl. RAID és gyorsítótárazási funkciók kikapcsolása), lehetővé téve az eszközök csatlakoztatását minimális változtatásokkal a ZFS-lemez I/O útvonalon. A JBOD módban lévő RAID-kártya továbbra is zavarhatja, ha gyorsítótára van, vagy kialakításától függően leválaszthatja azokat a meghajtókat, amelyek nem reagálnak időben (mint sok energiahatékony fogyasztói minőségű merevlemeznél tapasztaltuk), és mint ilyen , időkorlátozott hiba-helyreállítási (TLER)/CCTL/ERC-kompatibilis meghajtókat igényelhet, amelyek megakadályozzák a meghajtó kiesését, ezért nem minden kártya alkalmas a RAID funkciók letiltására is.

A ZFS megközelítése: RAID-Z és tükrözés

A hardveres RAID helyett a ZFS "puha" RAID-t alkalmaz, RAID-Z-t ( paritás alapú, mint a RAID 5 és hasonló) és lemez-tükrözést kínálva (hasonlóan a RAID 1-hez ). A rendszerek rendkívül rugalmasak.

A RAID-Z olyan adat/paritáselosztási séma, mint a RAID-5 , de dinamikus sávszélességet használ: minden blokk a saját RAID-csíkja, függetlenül a blokk méretétől, így minden RAID-Z írás teljes csíkos írás. Ez a ZFS másolás-írás-tranzakciós szemantikájával kombinálva kiküszöböli az írási lyuk hibáját . A RAID-Z gyorsabb is, mint a hagyományos RAID 5, mert nem kell elvégeznie a szokásos olvasás-módosítás-írás sorozatot.

Mivel minden csík különböző méretű, a RAID-Z rekonstrukciónak át kell járnia a fájlrendszer metaadatait a tényleges RAID-Z geometria meghatározásához. Ez lehetetlen lenne, ha a fájlrendszer és a RAID tömb külön termékek lennének, míg megvalósíthatóvá válik, ha integrált nézet van az adatok logikai és fizikai szerkezetére. A metaadatok áttekintése azt jelenti, hogy a ZFS minden blokkot érvényesíthet a 256 bites ellenőrző összege alapján, miközben a hagyományos RAID termékek általában nem képesek erre.

A teljes lemez hibáinak kezelése mellett a RAID-Z felismeri és kijavítja a csendes adat sérülést is , "öngyógyító adatokat" kínálva: a RAID-Z blokk olvasásakor a ZFS összehasonlítja azt az ellenőrző összegével, és ha az adatlemezek nem adja vissza a helyes választ, a ZFS beolvassa a paritást, majd kitalálja, hogy melyik lemez adott rossz adatokat. Ezután megjavítja a sérült adatokat, és jó adatokat ad vissza a kérőnek.

A RAID-Z és a tükrözés nem igényel különleges hardvert: a megbízhatósághoz nincs szükségük NVRAM-ra, és nincs szükség íráspufferre a jó teljesítmény vagy adatvédelem érdekében. A RAID-Z-vel a ZFS gyors és megbízható tárolást biztosít olcsó árucikkek használatával.

Öt különböző RAID-Z mód létezik: csíkozás (hasonlóan a RAID 0-hoz, nem kínál redundanciát), RAID-Z1 (hasonlóan a RAID 5-hez, lehetővé teszi egy lemez meghibásodását), RAID-Z2 (a RAID 6-hoz hasonlóan két lemez sikertelen), RAID-Z3 (egy RAID 7 konfiguráció, amely három lemez meghibásodását teszi lehetővé), és a tükrözés (a RAID 1-hez hasonlóan egy kivételével minden lemez meghibásodását teszi lehetővé).

A RAID-Z3 igénye a 2000-es évek elején merült fel, amikor a több terabájtos kapacitású meghajtók gyakoribbá váltak. Ez a kapacitásnövekedés - az átviteli sebesség megfelelő növelése nélkül - azt jelentette, hogy egy tömb megújítása meghibásodott meghajtó miatt "hetekig vagy akár hónapokig" is eltarthat. Ez idő alatt a tömb régebbi lemezeit a további munkaterhelés hangsúlyozza, ami adatok sérülését vagy meghajtó meghibásodását eredményezheti. A paritás növelésével a RAID-Z3 csökkenti az adatvesztés esélyét a redundancia növelésével.

Átalakítás és súrolás (tömbszinkronizálás és integritás -ellenőrzés)

A ZFS nem rendelkezik az fsck -vel egyenértékű eszközzel (a szabványos Unix és Linux adatellenőrző és -javító eszköz fájlrendszerekhez). Ehelyett a ZFS beépített súroló funkcióval rendelkezik, amely rendszeresen megvizsgál minden adatot, és kijavítja a csendes korrupciót és egyéb problémákat. Néhány különbség:

• Az fsck -et offline fájlrendszeren kell futtatni, ami azt jelenti, hogy a fájlrendszert le kell szerelni, és nem használható javítás közben, míg a scrub -ot egy csatlakoztatott, élő fájlrendszeren való használatra tervezték, és nem szükséges, hogy a ZFS fájlrendszer offline legyen.
• Az fsck általában csak a metaadatokat (például a naplónaplót) ellenőrzi, de magát az adatot soha. Ez azt jelenti, hogy egy fsck után előfordulhat, hogy az adatok még mindig nem egyeznek az eredeti tárolt adatokkal.
• Az fsck nem mindig tudja ellenőrizni és javítani az adatokat, ha ellenőrző összegeket tárolnak az adatokkal (ez gyakran előfordul sok fájlrendszerben), mert az ellenőrző összegek is sérültek vagy olvashatatlanok. A ZFS mindig ellenőrzött összegeket tárol az ellenőrzött adatoktól, javítva a megbízhatóságot és a súroló képességét a kötet javítására. A ZFS több adatpéldányt is tárol - a metaadatok különösen 4 vagy 6 példányban lehetnek (több példány lemezenként és több lemeztükrönként kötetenként), ami jelentősen javítja a bozót képességét a kötet kiterjedt károsodásának észlelésére és helyreállítására, az fsck -hez képest.
• A scrub mindent ellenőriz, beleértve a metaadatokat és az adatokat is. A hatás megfigyelhető az fsck és a súrolási idő összehasonlításával - néha egy nagy RAID fsck néhány perc alatt elkészül, ami azt jelenti, hogy csak a metaadatokat ellenőrizték. Az összes metaadat és adat bejárása nagy RAID -on sok órát vesz igénybe, pontosan ezt teszi a bozót.

A Sun/Oracle hivatalos ajánlása szerint havonta egyszer súrolja a vállalati szintű lemezeket, hetente egyszer az olcsóbb árucikkeket.

Kapacitás

A ZFS egy 128 bites fájlrendszer, így 1,84 × 10 ^19- szer több adatot képes kezelni, mint a 64 bites rendszerek, például a Btrfs . A ZFS maximális határait olyan nagyra tervezték, hogy a gyakorlatban soha ne lépjenek fel velük. Például egyetlen zpool teljes feltöltéséhez 2 ¹²⁸ bit adat szükséges 3 × 10 ²⁴  TB -os merevlemez -meghajtó.

Néhány elméleti korlátozás a ZFS -ben:

• 16 exbibájt (2 ⁶⁴ bájt): egyetlen fájl maximális mérete
• 2 ⁴⁸ : a bejegyzések száma bármely egyedi könyvtárban
• 16 exbibájt: bármely attribútum maximális mérete
• 2 ⁵⁶ : a fájl attribútumainak száma (valójában 2 ⁴⁸ -ra korlátozva a könyvtárban lévő fájlok száma)
• 256 quadrillion zebibytes (2 ¹²⁸ byte): bármely zpool maximális mérete
• 2 ⁶⁴ : az eszközök száma bármely zpoolban
• 2 ⁶⁴ : fájlrendszerek száma egy zpoolban
• 2 ⁶⁴ : zpoolok száma egy rendszerben

Titkosítás

Az Oracle Solaris segítségével a ZFS titkosítási képessége beágyazódik az I/O folyamatba. Írás közben a blokk ebben a sorrendben tömöríthető, titkosítható, ellenőrző összegezhető, majd ismétlődő. A titkosítási házirend az adatkészletek szintjén kerül beállításra, amikor adatkészleteket (fájlrendszereket vagy ZVOL -okat) hoznak létre. A felhasználó/rendszergazda által biztosított csomagoló kulcsok bármikor megváltoztathatók anélkül, hogy a fájlrendszert offline állapotba helyeznék. Az alapértelmezett viselkedés az, hogy a csomagoló kulcsot minden gyermek adathalmaz örökölheti. Az adattitkosítási kulcsok véletlenszerűen generálódnak az adatkészlet létrehozásakor. Csak a leszármazott adathalmazok (pillanatképek és klónok) osztanak meg titkosítási kulcsokat. A klónhoz vagy bármikor új adattitkosító kulcsra való váltásra vonatkozó parancsot kapunk-ez nem titkosítja újra a már meglévő adatokat, hanem egy titkosított master-kulcs mechanizmust használ.

2019 -től a titkosítási funkció teljesen integrálva van az OpenZFS 0.8.0 verziójába, amely elérhető a Debian és az Ubuntu Linux disztribúciókhoz.

Olvasási/írási hatékonyság

A ZFS automatikusan kiosztja az adattárolást a készlet összes vdev -jére (és minden eszközre minden eszközön) oly módon, hogy általában maximalizálja a készlet teljesítményét. A ZFS frissíti írási stratégiáját is, hogy figyelembe vegye a készlethez hozzáadott új lemezeket, amikor azokat hozzáadják.

Általános szabály, hogy a ZFS az írásokat a vdev -ek között osztja fel az egyes vdev -ek szabad területe alapján. Ez biztosítja, hogy azok a vdev -ek, amelyek arányosan kevesebb adatot tartalmaznak, több írást kapjanak az új adatok tárolásakor. Ez segít annak biztosításában, hogy a készlet egyre elterjedtebb használata esetén ne alakuljon ki az a helyzet, hogy egyes vdev -ek megteljenek, és az írások korlátozott számú eszközre kényszerülnek. Ez azt is jelenti, hogy amikor az adatokat olvassák (és az olvasások a legtöbb esetben sokkal gyakoribbak, mint az írások), akkor az adatok különböző részei a lehető legtöbb lemezről olvashatók le egyszerre, ami sokkal nagyobb olvasási teljesítményt nyújt. Ezért főszabályként a készleteket és a vdev -eket kell kezelni, és új tárhelyet kell hozzáadni, nehogy az a helyzet álljon elő, hogy a medencében egyes vdev -ek majdnem megteltek, mások pedig majdnem üresek, mivel ezáltal a készlet kevésbé lesz hatékony.

Más funkciók

Tárolóeszközök, tartalékok és kvóták

A medencék forró alkatrészekkel rendelkezhetnek a meghibásodott lemezek kompenzálására. Tükrözéskor a blokkeszközök fizikai alváz szerint csoportosíthatók, így a fájlrendszer folytatódhat egy egész ház meghibásodása esetén.

A tárolókészlet összetétele nem korlátozódik a hasonló eszközökre, hanem ad hoc, heterogén eszközgyűjteményekből állhat, amelyeket a ZFS zökkenőmentesen egyesít, és szükség szerint kiosztja a helyet a különböző fájlrendszereknek . A meglévő készletekhez tetszőleges típusú tárolóeszközöket lehet hozzáadni méretük növelése érdekében.

Az összes vdev tárolókapacitása a zpool összes fájlrendszer -példánya számára elérhető. A kvóta lehet állítani, hogy korlátozzák a tárterületet a fájlrendszer példánya lehet elfoglalni, és a fenntartás lehet állítani, hogy garantálni, hogy a tér lesz elérhető a fájlrendszer példánya.

Gyorsítótárazási mechanizmusok: ARC, L2ARC, Tranzakciós csoportok, ZIL, SLOG, Speciális VDEV

A ZFS a lemez gyorsítótárának különböző rétegeit használja az olvasási és írási műveletek felgyorsítására. Ideális esetben minden adatot RAM -ban kell tárolni, de ez általában túl drága. Ezért az adatok automatikusan gyorsítótárba kerülnek a hierarchiában a teljesítmény és a költség optimalizálása érdekében; ezeket gyakran "hibrid tárolómedencéknek" nevezik. A gyakran hozzáférett adatok a RAM -ban tárolódnak, a ritkábban hozzáférhető adatok pedig lassabb adathordozón, például szilárdtestalapú meghajtókon (SSD -k). Azokat az adatokat, amelyekhez gyakran nem fér hozzá, nem tárolja gyorsítótárban, és nem hagyja a lassú merevlemezeken. Ha a régi adatokat hirtelen sokat olvassák, a ZFS automatikusan áthelyezi azokat SSD -re vagy RAM -ra.

A ZFS gyorsítótárazási mechanizmusai egy -egy olvasást és írást tartalmaznak, és minden esetben két szintű gyorsítótárazás létezhet, az egyik a számítógép memóriájában (RAM) és a másik a gyors tároláson (általában szilárdtestalapú meghajtók (SSD -k)), összesen négy gyorsítótárak.

	Hol tárolják	Olvassa el a gyorsítótárat	Írjon gyorsítótárat
Első szintű gyorsítótár	RAM -ban	ARC néven ismert , mivel az adaptív csere gyorsítótár (ARC) algoritmus egyik változatát használja. A RAM -ot mindig gyorsítótárazásra használják, így ez a szint mindig jelen van. Az ARC algoritmus hatékonysága azt jelenti, hogy a lemezeket gyakran nem kell elérni, feltéve, hogy az ARC mérete elég nagy. Ha a RAM túl kicsi, alig lesz ARC; ebben az esetben a ZFS -nek mindig hozzá kell férnie az alapul szolgáló lemezekhez, ami jelentősen befolyásolja a teljesítményt.	"Tranzakciócsoportok" segítségével kezelik - az írásokat rövid időn belül (jellemzően 5 - 30 másodperc) összegyűjti egy adott határértékig, minden csoportot ideális esetben lemezre írva, míg a következő csoport összegyűjtése folyamatban van. Ez lehetővé teszi az írások hatékonyabb megszervezését az alapul szolgáló lemezek számára, azzal a kockázattal, hogy a legutóbbi tranzakciók kisebb adatvesztést okoznak áramszünet vagy hardverhiba esetén. A gyakorlatban a hálózati veszteség veszély kiküszöbölhető ZFS írási naplózó és az üt / ZIL második szint írási gyorsítótár medence (lásd alább), így ír csak elvesznek, ha az írási hiba történik ugyanabban az időben, mint a teljes veszteség a második rétegű SLOG -készletet, majd csak akkor, ha a szinkronírással és a SLOG használatával kapcsolatos beállításokat úgy állították be, hogy lehetővé tegyék egy ilyen helyzet kialakulását. Ha az adatok gyorsabban érkeznek, mint amennyit meg lehet írni, az adatfogadás szünetel, amíg a lemezek fel nem érnek.
Második szintű gyorsítótár	Gyors tárolóeszközökön (amelyek zavartalanul hozzáadhatók vagy eltávolíthatók az "élő" rendszerből a ZFS jelenlegi verzióiban, bár nem mindig a régebbi verziókban)	L2ARC ("Level 2 ARC") néven ismert , opcionális. A ZFS a lehető legtöbb adatot tárolja gyorsítótárban az L2ARC -ben, ami sok esetben több tíz vagy száz gigabájt lehet. Az L2ARC szintén jelentősen felgyorsítja a deduplikációt, ha a teljes deduplikációs táblázat gyorsítótárazható az L2ARC -ban. Több órába is beletelhet, amíg az L2ARC -t teljesen ki kell tölteni üresből (mielőtt a ZFS eldöntötte volna, hogy melyik adat "forró", és gyorsítótárazni kell). Ha az L2ARC eszköz elveszik, az összes leolvasás a lemezekre megy, ami lelassítja a teljesítményt, de semmi más nem történik (adatok nem vesznek el).	Ismert, mint a robot vagy ZIL ( „ZFS szándék Log”) - ezeket a kifejezéseket gyakran helytelenül használják. A SLOG (másodlagos naplóeszköz) egy opcionális dedikált gyorsítótár külön eszközön az írások rögzítésére, rendszerhiba esetén. Ha létezik SLOG -eszköz, akkor azt a ZFS szándéknaplóhoz használják második szintű naplóként, és ha nincs külön gyorsítótár -eszköz, akkor a ZIL a fő tárolóeszközökön jön létre. A SLOG tehát technikailag arra a dedikált lemezre utal, amelyre a ZIL -t le kell tölteni a készlet felgyorsítása érdekében. Szigorúan véve a ZFS nem használja a SLOG eszközt a lemez írásának gyorsítótárazására. Inkább a SLOG -ot használja annak biztosítására, hogy az írásokat a lehető leggyorsabban rögzítsük egy állandó adathordozóra, így áramszünet vagy írási hiba esetén egyetlen adat sem fog elveszni. A SLOG eszköz lehetővé teszi a ZFS számára, hogy gyorsan tárolja az írásokat, és gyorsan írva jelentse azokat, még olyan tárolóeszközök esetében is, mint a sokkal lassabb merevlemezek . A szokásos tevékenységek során a SLOG -ra soha nem hivatkoznak és nem olvassák, és nem működik gyorsítótárként; célja a repülés közbeni adatok védelme az összeállításhoz és a "kiíráshoz" szükséges néhány másodpercben, arra az esetre, ha az esetleges írás meghiúsulna. Ha minden jól megy, akkor a tárolókészlet egy bizonyos ponton frissül a következő 5–60 másodpercben, amikor az aktuális tranzakciós csoportot kiírják a lemezre (lásd fent), ekkor a SLOG -ban tárolt írások egyszerűen figyelmen kívül hagyva és felülírva. Ha az írás végül meghiúsul, vagy a rendszer összeomlik vagy meghibásodik, ami megakadályozza az írást, akkor a ZFS a SLOG visszaolvasásával (ez az egyetlen alkalom, amikor olvasható) azonosítani tudja az összes olyan írást, amelyről megerősítette, hogy íródott, és ezt használja az adatvesztés teljes helyreállításához. Ez döntő fontosságúvá válik, ha nagyszámú szinkron írás történik (például ESXi , NFS és egyes adatbázisok esetén ), ahol az ügyfélnek meg kell erősítenie a sikeres írást, mielőtt folytatja tevékenységét; a SLOG lehetővé teszi a ZFS számára, hogy sokkal gyorsabban megerősítse az írás sikerét, mintha minden alkalommal a fő tárolóba kellene írnia, anélkül, hogy az ügyfél félrevezetné az adattárolás állapotát. Ha nincs SLOG -eszköz, akkor a fő adatkészlet egy részét ugyanarra a célra használják fel, bár ez lassabb. Ha maga a naplóeszköz elveszik, akkor a legújabb írások elveszhetnek, ezért a naplóeszközt tükrözni kell. A ZFS korábbi verzióiban a naplóeszköz elvesztése a teljes zpool elvesztését eredményezheti, bár ez már nem így van. Ezért frissíteni kell a ZFS -t, ha külön naplóeszközt tervez használni.

A ZFS -en belül számos más gyorsítótár, gyorsítótár -felosztás és sor is létezik. Például minden VDEV saját adatgyorsítótárral rendelkezik, és az ARC gyorsítótár fel van osztva a felhasználó által tárolt adatok és a ZFS által használt metaadatok között, az ezek közötti egyensúly szabályozásával.

Különleges VDEV osztály

Az OpenZFS 0.8 és újabb verzióiban lehetőség van egy speciális VDEV osztály konfigurálására a fájlrendszer metaadatainak, és opcionálisan az adatduplikációs táblának (DDT), valamint a kis fájlrendszer blokkoknak a tárolására. Ez lehetővé teszi például egy speciális VDEV létrehozását a gyors SSD tárolón a metaadatok tárolására, míg a normál fájladatokat a forgó lemezeken tárolják. Ez felgyorsítja a metaadat-intenzív műveleteket, például a fájlrendszer-átjárást, a súrolást és a továbbfejlesztést anélkül, hogy a teljes fájlrendszert szilárdtestalapú tárolón tárolná.

Másolás-írás tranzakciós modell

A ZFS másolási és írási tranzakciós objektum modellt használ . A fájlrendszeren belül minden blokkmutató tartalmaz egy 256 bites ellenőrző összeget vagy 256 bites kivonatot (jelenleg a Fletcher-2 , Fletcher-4 vagy SHA-256 közül választhat ) a célblokkot, amelyet a blokk olvasásakor ellenőriznek. Az aktív adatokat tartalmazó blokkokat soha nem írják felül a helyükön; ehelyett egy új blokkot rendelnek hozzá, módosított adatokat írnak hozzá, majd az arra hivatkozó metaadat -blokkokat hasonlóan olvassák, osztják fel és írják le. Ennek a folyamatnak a költségeinek csökkentése érdekében több frissítést tranzakciócsoportokba csoportosítanak, és ZIL ( szándéknapló ) írási gyorsítótárat használnak, ha szinkron írási szemantika szükséges. A blokkok egy fában vannak elrendezve, csakúgy, mint az ellenőrző összegeik (lásd Merkle aláírási sémáját ).

Pillanatképek és klónok

Az írás-másolás előnye, hogy amikor a ZFS új adatokat ír, a régi adatokat tartalmazó blokkok megtarthatók, lehetővé téve a fájlrendszer pillanatképes verziójának fenntartását. A ZFS -pillanatképek konzisztensek (a teljes adatot tükrözik, ahogyan egy adott időpontban léteztek), és rendkívül gyorsan létrehozhatók, mivel a pillanatfelvételt alkotó összes adat már tárolva van, és a teljes tárolót gyakran óránként többször is lefényképezik . Helytakarékosak is, mivel a változatlan adatok megosztásra kerülnek a fájlrendszer és a pillanatfelvételek között. A pillanatfelvételek természetüknél fogva csak olvashatóak, biztosítva, hogy a létrehozás után nem módosulnak, bár nem szabad a biztonsági mentés kizárólagos eszközeként támaszkodni rájuk. Visszaállíthatók a teljes pillanatképek, valamint a pillanatképeken belüli fájlok és könyvtárak.

Írható pillanatképek ("klónok") is létrehozhatók, ami két független fájlrendszert eredményez, amelyek blokkok halmazát osztják meg. A klónozó fájlrendszerek bármelyikén végrehajtott változtatások során új adatblokkok jönnek létre, amelyek tükrözik ezeket a változásokat, de a változatlan blokkok továbbra is megosztásra kerülnek, függetlenül attól, hogy hány klón létezik. Ez a másolás az írásra elv megvalósítása.

Pillanatképek küldése és fogadása

A ZFS fájlrendszerek áthelyezhetők más készletekbe is, távoli gépeken a hálózaton keresztül, mivel a send parancs a fájlrendszer állapotának adatfolyam -ábrázolását hozza létre. Ez a folyam vagy leírhatja a fájlrendszer teljes tartalmát egy adott pillanatképnél, vagy delta lehet a pillanatképek között. A delta adatfolyam kiszámítása nagyon hatékony, mérete pedig a pillanatképek között megváltozott blokkok számától függ. Ez hatékony stratégiát biztosít, például a külső biztonsági mentések vagy a medence magas rendelkezésre állású tükreinek szinkronizálásához.

Dinamikus csíkozás

A dinamikus csíkozás minden eszközön az áteresztés maximalizálása érdekében azt jelenti, hogy ahogy további eszközök kerülnek a zpoolba, a csík szélessége automatikusan kibővül, hogy azokat is tartalmazza; így a készlet összes lemezét használják, ami kiegyenlíti az írási terhelést.

Változó méretű blokkok

A ZFS változó méretű blokkokat használ, alapértelmezett mérete 128 KB. Az elérhető funkciók lehetővé teszik a rendszergazda számára a maximális blokkméret beállítását, mivel bizonyos munkaterhelések nem teljesítenek jól nagy blokkok esetén. Ha az adattömörítés engedélyezve van, változó blokkméreteket használnak. Ha egy blokk tömöríthető, hogy kisebb blokkméretbe illeszkedjen, akkor a kisebb méretet használják a lemezen, hogy kevesebb tárhelyet használjon, és javítsa az IO -teljesítményt (bár a tömörítési és dekompressziós műveletek fokozott CPU -felhasználásának árán).

Könnyű fájlrendszer létrehozása

A ZFS -ben a fájlrendszer manipulálása egy tárolókészleten belül könnyebb, mint a hagyományos fájlrendszeren belüli kötetmanipuláció; a ZFS fájlrendszer létrehozásához vagy kibővítéséhez szükséges idő és erőfeszítés közelebb áll az új könyvtár létrehozásához, mint néhány más rendszer kötetkezeléséhez.

Adaptív végletesség

A készletek és a hozzájuk tartozó ZFS fájlrendszerek áthelyezhetők a különböző platform architektúrák között, beleértve a különböző bájtrendeléseket megvalósító rendszereket is. A ZFS blokk mutató formátumú üzletek fájlrendszer metaadatok egy endian -adaptive módon; az egyes metaadat -blokkok a blokkot író rendszer natív bájtsorrendjével íródnak. Olvasáskor, ha a tárolt végletesség nem egyezik a rendszer végtelenségével, akkor a metaadatok bájtosan cserélődnek a memóriában.

Ez nem befolyásolja a tárolt adatokat; a POSIX rendszerekben megszokott módon a fájlok egyszerű bájttömbként jelennek meg az alkalmazások számára, így az adatokat létrehozó és olvasó alkalmazások továbbra is felelősek az alaprendszer végtelenségétől független módon.

Duplikáció

Az adatok deduplikációs képességei 2009. október végén kerültek a ZFS forrástárába, és a vonatkozó OpenSolaris ZFS fejlesztési csomagok 2009. december 3. óta elérhetők (128 -as verzió).

A deduplikáció hatékony használata nagy RAM -kapacitást igényelhet; az ajánlások 1 TB és 5 GB RAM között mozognak minden TB tárhely esetén. A deduplikációhoz szükséges memória pontos értékelését a készletben található egyedi blokkok, valamint a lemez és a RAM ("core") bájtjai alapján kell elvégezni az egyes rekordok tárolásához - ezeket a számokat a beépített adatok jelentik olyan parancsokat, mint a zpool és a zdb . Az elégtelen fizikai memória vagy a ZFS gyorsítótár hiánya a deduplikáció használatakor a virtuális memória tönkremeneteléhez vezethet, ami a teljesítmény csökkenéséhez vagy a memória teljes éhezéséhez vezethet. Mivel a deduplikáció írási időben történik, emellett nagyon processzorigényes is, és ez szintén jelentősen lelassíthatja a rendszert.

Más tárolási gyártók a ZFS módosított verzióit használják a nagyon magas adattömörítési arány eléréséhez . 2012 -ben két példa volt a GreenBytes és a Tegile. 2014 májusában az Oracle megvásárolta a GreenBytes ZFS deduplikációs és replikációs technológiáját.

Amint azt fentebb leírtuk, a deduplikáció általában nem ajánlott a nagy erőforrásigénye (különösen a RAM) és a teljesítményre gyakorolt ​​hatása miatt (különösen írás közben), kivéve azokat a különleges körülményeket, amikor a rendszer és az adatok jól illeszkednek ehhez a helytakarékos technikához.

További képességek

• Kifejezett I/O prioritás határidő ütemezéssel.
• Globálisan optimális I/O válogatás és összesítés.
• Több független előhívási adatfolyam automatikus hossz- és lépésfelismeréssel.
• Párhuzamos, állandó idejű könyvtári műveletek.
• Végső ellenőrző összegzés, egyfajta " Adatintegritási mező " használatával, amely lehetővé teszi az adatok sérüléseinek észlelését (és helyreállítást, ha redundancia van a készletben). Három kivonat közül választhat, optimalizálva a sebességre (fletcher), a szabványosításra és a biztonságra ( SHA256 ), valamint a sózott kivonatokra ( Skein ).
• Átlátszó fájlrendszer -tömörítés. Támogatja az LZJB , gzip és LZ4 .
• Intelligens súrolás és újratervezés (újraszinkronizálás).
• Terhelés és helykihasználás megosztása a medencében lévő lemezek között.
• Ugyanazok a blokkok: konfigurálható adatreplikáció fájlrendszerenként, nulla, írásonként egy vagy két extra másolat kérése a felhasználói adatokhoz, és ugyanazzal a példányszámmal plusz egy vagy kettő a metaadatokhoz (a metaadatok fontossága szerint). Ha a készlet több eszközzel rendelkezik, a ZFS megpróbálja megismételni a különböző eszközöket. A hasonló blokkok elsősorban kiegészítő védelmet nyújtanak a sérült szektorok ellen, nem pedig a teljes lemezhiba ellen.
• A ZFS tervezés (másolás-írás + szuperblokkok) biztonságos, ha engedélyezett írási gyorsítótárral rendelkező lemezeket használ, ha tiszteletben tartják az írási korlátokat. Ez a szolgáltatás biztonságot és teljesítménynövelést biztosít néhány más fájlrendszerhez képest.
• A Solaris rendszeren, amikor egész lemezeket adnak hozzá egy ZFS készlethez, a ZFS automatikusan engedélyezi az írási gyorsítótárat. Ez nem történik meg, ha a ZFS csak a lemez diszkrét szeleteit kezeli, mivel nem tudja, hogy a többi szeletet nem írási gyorsítótárban lévő biztonságos fájlrendszerek, például az UFS kezeli-e . A FreeBSD implementáció a GEOM keretrendszerének köszönhetően képes kezelni a partíciók öblítéseit , ezért nem szenved ezektől a korlátozásoktól.
• Felhasználói, csoportonkénti, projektenkénti és adathalmazonkénti korlát.
• Fájlrendszer titkosítás a Solaris 11 Express és az OpenZFS (ZoL) 0.8 óta. (néhány más rendszeren a ZFS használhat titkosított lemezeket hasonló hatás eléréséhez ; a FreeBSD -n található GELI így használható teljesen titkosított ZFS tároló létrehozásához).
• A készletek csak olvasható módban importálhatók.
• Lehetőség van az adatok helyreállítására a teljes tranzakció visszagörgetésével a zpool importálásakor.
• A ZFS nem fürtözött fájlrendszer ; a fürtözött ZFS azonban harmadik felektől elérhető.
• A pillanatfelvételek manuálisan vagy automatikusan készíthetők. A tárolt adatok régebbi verziói, amelyeket tartalmaznak, teljes írásvédett fájlrendszerként jeleníthetők meg. A fájlok és mappák korábbi verzióiként is megjeleníthetők, ha CIFS -sel használják (más néven SMB, Samba vagy fájlmegosztások ); ezt "Előző verziók", "VSS árnyékmásolatok" vagy "Fájltörténet" néven ismerik Windows rendszeren , vagy AFP és "Apple Time Machine" néven Apple eszközökön.
• A lemezek „tartalékként” jelölhetők. Az adatkészlet beállítható úgy, hogy automatikusan és átláthatóan kezelje a lemezhibákat, ha aktivál egy tartaléklemezt, és szükség esetén elkezdi újratervezni a gyanús lemezen lévő adatokat.

Korlátozások

A ZFS fájlrendszer számos korlátozással rendelkezik.

Korlátozások az adatkorrupció megelőzésében

Egy 2010 -es tanulmány szerzői, amely a fájlrendszerek azon képességét vizsgálta, hogy felismerjék és megakadályozzák az adatkorrupciót, különös tekintettel a ZFS -re, megfigyelte, hogy a ZFS maga is hatékonyan észleli és javítja az adathibákat a tárolóeszközökön, de feltételezi, hogy a RAM -ban lévő adatok "biztonságos", és nem hajlamos a hibákra. A tanulmány megjegyzi, hogy "egyetlen bites fordulat a memóriában a futások kicsi, de nem elhanyagolható hányadát okozza, és a hibás adatok lemezre történő elküldésének valószínűsége 0% és 3,6% között változik (a munkaterhelés szerint)", és hogy amikor a ZFS gyorsítótárazza az oldalakat vagy tárolja a metaadatok másolatait a RAM -ban, vagy adatokat tárol a "piszkos" gyorsítótárában a lemezre íráshoz, akkor nem tesztelik, hogy az ellenőrző összegek még mindig megfelelnek -e az adatoknak a használat helyén. Ennek a kockázatnak a nagy része kétféleképpen csökkenthető:

• A szerzők szerint az ECC RAM használatával ; a szerzők azonban úgy vélték, hogy az oldal gyorsítótárához és a halomhoz kapcsolódó hibafelismerés hozzáadása lehetővé tenné a ZFS számára, hogy robusztusabban kezelje bizonyos hibaosztályokat.
• A ZFS egyik fő építésze, Matt Ahrens elmagyarázza, hogy van lehetőség a memóriában lévő adatok ellenőrző összegezésének engedélyezésére a ZFS_DEBUG_MODIFY zászló használatával (zfs_flags = 0x10), amely ezeket a problémákat orvosolja.

A ZFS -re vonatkozó egyéb korlátozások

• A kapacitásbővítést általában úgy érik el, hogy lemezcsoportokat adnak hozzá legfelső szintű vdev-ként: egyszerű eszköz, RAID-Z , RAID Z2, RAID Z3 vagy tükrözve. Az újonnan írt adatok dinamikusan elkezdik használni az összes elérhető vdev -et. Lehetőség van arra is, hogy kibővítsük a tömböt, ha a tömb minden meghajtóját ismételten kicseréljük egy nagyobb meghajtóra, és várjuk, amíg a ZFS öngyógyul; a gyógyulási idő a tárolt információ mennyiségétől, nem pedig a lemez méretétől függ.
• A Solaris 10 Update 11 és a Solaris 11.2 verziójától kezdve nem lehetett csökkenteni a medencében lévő legfelső szintű vdev-ek számát, kivéve a tartalék tartalékokat, a gyorsítótárat és a naplóeszközöket, és más módon sem csökkenteni a medencekapacitást. Ezt a funkciót 2007 -ben fejlesztették ki. Az OpenZFS -ben fejlesztés alatt állnak a vdev -ek csökkentését lehetővé tevő fejlesztések. Az online zsugorodás a nem redundáns felső szintű vdev-ek eltávolításával támogatott, mivel a Solaris 11.4 2018 augusztusában és az OpenZFS (ZoL) 0.8 2019 májusában megjelent.
• 2008 -tól nem lehetett lemezt oszlopként hozzáadni egy RAID Z, RAID Z2 vagy RAID Z3 vdev eszközhöz. Helyette azonban új RAID Z vdev létrehozható, és hozzáadható a zpoolhoz.
• Néhány hagyományos beágyazott RAID-konfiguráció, például a RAID 51 (a RAID 5 csoportok tükre), nem konfigurálható a ZFS-ben, külső gyártók eszközei nélkül. A Vdev -ek csak nyers lemezekből vagy fájlokból állhatnak össze, más vdev -ek nem, az alapértelmezett ZFS felügyeleti parancsok használatával. A ZFS -készlet azonban ténylegesen csíkot (RAID 0) hoz létre a vdevs -en, így a RAID 50 vagy RAID 60 megfelelője gyakori.
• A felső szintű vdev eszközeinek újrakonfigurálásához offline adatok másolása, a készlet megsemmisítése és a készlet újbóli létrehozása az új felső szintű vdev konfigurációval, kivéve extra redundancia hozzáadását egy meglévő tükörhöz, ami bármikor elvégezhető vagy ha az összes legfelső szintű vdevs elégséges redundanciájú tükrök, akkor a zpool split paranccsal eltávolítható egy vdev a készlet minden felső szintű vdev -ből, létrehozva egy második készletet azonos adatokkal.
• A ZFS tároló IOPS teljesítménye szenvedhet, ha a ZFS raid nincs megfelelően konfigurálva. Ez a RAID minden típusára vonatkozik, így vagy úgy. Ha a zpool csak egy lemezcsoportból áll, például nyolc lemezként a RAID Z2 -ben, akkor az IOPS teljesítménye egyetlen lemez teljesítménye lesz (az írási sebesség 6 lemeznek felel meg, de a véletlenszerű olvasási sebesség hasonló lesz a egyetlen lemez). Vannak azonban módok az IOPS teljesítményproblémájának enyhítésére, például SSD -k hozzáadása L2ARC gyorsítótárként - ez 100 000 -re növelheti az IOPS -t. Röviden: egy zpoolnak több vdev -csoportból kell állnia, mindegyik vdev 8-12 lemezből áll, ha RAID Z -t használ. Nem ajánlott zpool -t létrehozni egyetlen nagy vdev -vel, mondjuk 20 lemezzel, mert az IOPS teljesítménye egyetlen lemezé, ami azt is jelenti, hogy a resilver idő nagyon hosszú lesz (valószínűleg hetek a jövőbeni nagy meghajtók esetén).
• A ZFS RAID meghibásodott lemezének újratervezése (javítása) hosszú időt vehet igénybe, ami nem egyedülálló a ZFS -hez, ez a RAID minden típusára vonatkozik, így vagy úgy. Ez azt jelenti, hogy a nagyon nagy volumenű javítások vagy a teljes redundancia helyreállítása súlyos adatvesztést vagy meghibásodást követően több napot is igénybe vehet, és ez idő alatt előfordulhat egy második lemezhiba, különösen, mivel a javítás további terhelést jelent a rendszer egészére nézve. . Ez viszont azt jelenti, hogy kerülni kell azokat a konfigurációkat, amelyek csak egyetlen lemezhiba helyreállítását teszik lehetővé, mint például a RAID Z1 (hasonlóan a RAID 5 -hez). Ezért nagy lemezek esetén a RAID Z2 (két lemez meghibásodása) vagy a RAID Z3 (három lemez meghibásodásának engedélyezése) lehetőséget kell használni. A ZFS RAID abban különbözik a hagyományos RAID -től, hogy csak az élő adatokat és a metaadatokat rekonstruálja a lemez cseréjekor, nem pedig a lemez egészét, beleértve az üres és a szemétblokkokat is, ami azt jelenti, hogy a tag lemez cseréje a csak részben megtelt ZFS -készleten arányosan kevesebb időt vesz igénybe a hagyományos RAID -hez képest.

Adat visszanyerés

A ZFS történelmileg nem szállított olyan eszközöket, mint az fsck a sérült fájlrendszerek javítására, mivel magát a fájlrendszert önjavításra tervezték, feltéve, hogy kellő figyelmet fordítottak a tárolás és az adatok redundanciájának kialakítására. Ha a készletet rossz hardver, nem megfelelő tervezés vagy redundancia vagy szerencsétlen szerencsétlenség miatt veszélyeztették, és a ZFS nem tudta felszerelni a medencét, akkor hagyományosan nem léteztek olyan eszközök, amelyek lehetővé tették a végfelhasználó számára, hogy megkísérelje a tárolt adatok részleges mentését. . Ez olyan fórumokhoz vezetett az online fórumokon, ahol a ZFS fejlesztői esetenként megpróbáltak ad-hoc segítséget nyújtani otthoni és más kisméretű felhasználóknak, mivel nem megfelelő kialakításuk vagy rossz rendszerkezelésük miatt adatvesztéssel kellett szembenézniük.

A modern ZFS az idő múlásával jelentősen javult ezen a helyzeten, és továbbra is ezt teszi:

• A gyorsítótárazó eszközök eltávolítása vagy hirtelen meghibásodása már nem okoz medenceveszteséget. (A legrosszabb esetben a ZIL elvesztése elveszítheti a legutóbbi tranzakciókat, de a ZIL általában nem tárol néhány másodpercnél többet a legutóbbi tranzakciókból. Az L2ARC gyorsítótár elvesztése nincs hatással az adatokra.)
• Ha a készlet fel nem szerelhető, a ZFS modern verziói megpróbálják azonosítani a legutóbbi konzisztens pontot, amelyen a készlet visszaállítható, a tartalom legutóbbi módosításainak elvesztésének árán. A másolás írásra azt jelenti, hogy az adatok régebbi verziói, beleértve a legfelső szintű rekordokat és a metaadatokat, még akkor is létezhetnek, ha felülírják őket, és ha igen, akkor a készletet ezek alapján egységes állapotba lehet visszaállítani. Minél régebbi az adat, annál valószínűbb, hogy legalább néhány blokkot felülírtak, és egyes adatok helyreállíthatatlanok lesznek, ezért egy bizonyos ponton korlátozás áll fenn a készlet visszacsévélésére.
• Informálisan vannak olyan eszközök, amelyek megvizsgálják annak okát, hogy a ZFS miért nem tud medencét szerelni, és útmutatást nyújtanak a felhasználónak vagy a fejlesztőnek a készlet kényszerítéséhez szükséges kézi változtatásokhoz. Ide tartozik a zdb (ZFS hibakeresés) használata egy érvényes importálható pont megtalálására a készletben, a dtrace vagy hasonló módszerrel a csatlakoztatási hibát okozó probléma azonosítására, vagy manuálisan megkerülve az állapotfelméréseket, amelyek miatt a csatlakoztatási folyamat megszakad, és lehetővé teszi a sérült medence felszerelését .
• 2018 márciusától fokozatosan számos jelentősen továbbfejlesztett módszer kerül bevezetésre az OpenZFS -en belül. Ezek tartalmazzák:

• Kódjavítás, valamint részletesebb diagnosztikai és hibakeresési információk a csatolási hibákról a korrupt készletproblémák diagnosztizálásának és javításának egyszerűsítése érdekében;
• Az a képesség, hogy megbízzon vagy bizalmatlan legyen a tárolt készlet konfigurációjában. Ez különösen erőteljes, mivel lehetővé teszi a medence felszerelését akkor is, ha a legfelső szintű vdev-ek hiányoznak vagy hibásak, ha a legfelső szintű adatok gyanúsak, és a készlet konfigurációjának módosításán túl is visszatekerhet, ha ez a változás a problémához kapcsolódik. A sérült készlet telepítése után az olvasható fájlok másolhatók a biztonság érdekében, és kiderülhet, hogy az adatok a hiányzó vdev -ek esetében is újjáépíthetők, a készletben máshol tárolt másolatok használatával.
• Az a képesség, hogy kijavítsuk azt a helyzetet, amikor az egyik készletben szükséges lemezt véletlenül eltávolítottuk, és hozzáadtuk egy másik készlethez, ami miatt elvesztette az első készlettel kapcsolatos metaadatokat, amelyek olvashatatlanná váltak.

OpenZFS és ZFS

Az Oracle Corporation a Sun 2010 -es felvásárlása után leállította mind a ZFS, mind az OpenSolaris nyilvános fejlesztését . Néhány fejlesztő az OpenSolaris utolsó nyilvános kiadását választotta Illumos projektként. A ZFS jelentős előnyei miatt több különböző platformra, különböző funkciókkal és parancsokkal portolták át. A fejlesztési erőfeszítések összehangolása és a töredezettség elkerülése érdekében az OpenZFS -t 2013 -ban alapították.

Matt Ahrens, a ZFS egyik fő építésze szerint az eredeti OpenSolaris ZFS kód több mint 50% -át lecserélték az OpenZFS -ben közösségi hozzájárulásokkal 2019 -től, így az „Oracle ZFS” és az „OpenZFS” politikailag és technológiailag összeegyeztethetetlenek.

Kereskedelmi és nyílt forráskódú termékek

• 2008: A Sun ZFS-alapú 7000-es sorozatú tárolóeszközöket szállított.
• 2013: Az Oracle szállította a ZS3 sorozatú ZFS-alapú reszelőit, és egyikükkel megszerezte az első helyet az SPC-2 benchmarkban.
• 2013: Az iXsystems ZFS-alapú, FreeNAS (most TrueNAS CORE) NAS-eszközöket szállít a SOHO és a TrueNAS számára a vállalat számára.
• 2014: A Netgear ZFS-alapú NAS-eszközök sorát szállítja ReadyDATA néven , amelyeket a vállalati használatra terveztek.
• 2015: Az rsync.net bejelentett egy felhőtárolási platformot, amely lehetővé teszi az ügyfelek számára, hogy saját zpool szolgáltatást biztosítsanak, és adatokat importáljanak és exportáljanak a zfs send és a zfs Receive használatával.
• 2020: Az iXsystems megkezdi a ZFS-alapú, TrueNAS SCALE nevű hiperkonvergált szoftver fejlesztését a SOHO és a TrueNAS számára a vállalat számára.

Oracle Corporation, zárt forráskódú és villás (2010 -től)

2010 januárjában az Oracle Corporation felvásárolta a Sun Microsystems -t, és gyorsan megszüntette az OpenSolaris terjesztést és a nyílt forráskódú fejlesztési modellt. 2010 augusztusában az Oracle abbahagyjuk a nyilvános frissítéseket a forráskód a Solaris OS / Hálózat adattár, hatékonyan fordult Solaris 11 vissza a zárt forráskódú tulajdonosi operációs rendszer.

A Solaris és az OpenSolaris változó környezetére reagálva az illumos projektet 2010. augusztus 3 -án, csütörtökön indították el webináriumon , néhány alapvető Solaris -mérnök közösségi erőfeszítéseként, hogy folytassák a Solaris nyílt forráskódú verziójának fejlesztését és befejezzék a nyílt forráskódú beszerzést azon részek közül, amelyeket még nem nyitott meg a Sun. Az illumos alapítványként jött létre, az illumos Foundation, amelyet Kalifornia államban 501 (c) 6 kereskedelmi szövetségként alapítottak . Az eredeti terv kifejezetten kimondta, hogy az illumos nem lesz elosztó vagy villa. Miután azonban az Oracle bejelentette az OpenSolaris megszüntetését, a Solaris ON végleges verziójának elágazását tervezték, lehetővé téve az illumosok számára, hogy saját operációs rendszerré fejlődjenek. Az OpenSolaris részeként a ZFS nyílt forráskódú változata ezért szerves része volt az illumosnak.

A ZFS -t széles körben használták számos platformon, valamint a Solarison is. Ezért 2013-ban a ZFS nyílt forráskódú verziójának fejlesztési munkáinak összehangolása egy esernyőprojektre , az OpenZFS-re hárult . Az OpenZFS keretrendszer lehetővé teszi az érdekelt felek számára, hogy közösen fejlesszék a közös ZFS kódbázist, miközben egyedileg fenntartanak minden speciális extra kódot, amelyre a ZFS a saját rendszereiben való működéshez és integráláshoz szüksége van.

Verziótörténet

Legenda:

Régi kiadás

A legújabb FOSS stabil kiadás

ZFS fájlrendszer verziószáma	Kiadási dátum	Jelentős változások
1	Az OpenSolaris Nevada 36 -os verziója	Első kiadás
2	OpenSolaris Nevada b69	Továbbfejlesztett könyvtárbejegyzések. Különösen a könyvtárbejegyzések tárolják az objektumtípust. Például fájl, könyvtár, elnevezett cső és így tovább, az objektumszám mellett.
3	OpenSolaris Nevada b77	ZFS fájlrendszerek SMB -n keresztüli megosztásának támogatása . Kis- és nagybetűk megkülönböztetésének támogatása. Rendszerattribútum -támogatás. Integrált vírusirtó támogatás.
4	OpenSolaris Nevada b114	Tulajdonságok: userquota, groupquota, userused és groupused
5	OpenSolaris Nevada b137	Rendszer attribútumok; szimbólumok most saját objektumtípusukat

ZFS Pool verziószáma	Kiadási dátum	Jelentős változások
1	OpenSolaris Nevada b36	Első kiadás
2	OpenSolaris Nevada b38	Ugyanazok a blokkok
3	OpenSolaris Nevada b42	Forró alkatrészek, kettős paritású RAID-Z (raidz2), továbbfejlesztett RAID-Z elszámolás
4	OpenSolaris Nevada b62	zpool története
5	OpenSolaris Nevada b62	gzip tömörítés ZFS adatkészletekhez
6	OpenSolaris Nevada b62	"bootfs" pool tulajdonság
7	OpenSolaris Nevada b68	ZIL: lehetővé teszi külön szándéknapló -eszköz vagy eszközök megadását
8	OpenSolaris Nevada b69	a zfs (1M) adminisztrációs feladatok átruházásának képessége a hétköznapi felhasználókra
9	OpenSolaris Nevada b77	CIFS szerver támogatás, adatkészlet kvóták
10	OpenSolaris Nevada b77	Az eszközök "tárolóeszközként" adhatók hozzá a tárolókészlethez
11	OpenSolaris Nevada b94	Továbbfejlesztett zpool súroló / rugalmasító teljesítmény
12	OpenSolaris Nevada b96	Pillanatfelvétel tulajdonságai
13	OpenSolaris Nevada b98	Tulajdonságok: usedbysnapshots, usedbychildren, usedbyrefreservation, and usedbydataset
14	OpenSolaris Nevada b103	passthrough-x aclinherit ingatlan támogatás
15	OpenSolaris Nevada b114	Tulajdonságok: userquota, groupquota, usuerused and groupused; FS v4 is szükséges
16	OpenSolaris Nevada b116	STMF ingatlan támogatás
17	OpenSolaris Nevada b120	hármas paritású RAID-Z
18	OpenSolaris Nevada b121	A ZFS pillanatkép megmarad
19	OpenSolaris Nevada b125	ZFS naplóeszköz eltávolítása
20	OpenSolaris Nevada b128	zle tömörítési algoritmus, amely szükséges a ZFS deduplikációs tulajdonságainak támogatásához a ZFS pool 21 verziójában, amelyeket egyidejűleg adtak ki
21	OpenSolaris Nevada b128	Duplikáció
22	OpenSolaris Nevada b128	zfs tulajdonságokat kap
23	OpenSolaris Nevada b135	karcsú ZIL
24	OpenSolaris Nevada b137	A rendszer attribútumai. A hivatkozások most már saját objektumtípusuk. FS v5 is szükséges.
25	OpenSolaris Nevada b140	Továbbfejlesztett medence -súrolási és átszervezési statisztikák
26	OpenSolaris Nevada b141	Javított pillanatkép törlési teljesítmény
27	OpenSolaris Nevada b145	Javított pillanatkép -készítési teljesítmény (különösen rekurzív pillanatképek)
28	OpenSolaris Nevada b147	Több virtuális eszközcsere

Megjegyzés: A Sun által fejlesztett Solaris verzió a Solaris 10 2005 -ös megjelenése óta „Nevada” kódnevű volt , és az OpenSolaris kódbázisból származik. A „Solaris Nevada” a következő generációs Solaris operációs rendszer kódneve, amely végül a Solaris 10 utódja lesz, és ezt az új kódot egymás után behúzták az új OpenSolaris „Nevada” pillanatképekbe. Az OpenSolaris most megszűnt, és az OpenIndiana elágazott tőle. Az OpenSolaris végső változatát (b134) az Oracle tette közzé (2010-november-12) a Solaris 11 Express frissítési útvonalaként .

A ZFS -t támogató operációs rendszerek listája

A ZFS-t támogató operációs rendszerek, disztribúciók és kiegészítők listája, az általuk támogatott zpool verzió és a Solaris-konstrukció (ha van ilyen):

OS	Zpool verzió	Sun/Oracle Build #	Hozzászólások
Oracle Solaris 11.4	47	SRU 21
Oracle Solaris 11.3	37	0.5.11-0.175.3.1.0.5.0
Oracle Solaris 10 1/13 (U11)	32
Oracle Solaris 11.2	35	0.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.11	34	b175
Oracle Solaris Express 11 2010.11	31	b151a	csak tesztelésre engedélyezett
OpenSolaris 2009.06	14	b111b
OpenSolaris (utolsó fejlesztő)	22	b134
OpenIndiana	5000	b147	illumos alapú elosztás ; névütközést hoz létre, és elnevezi építési kódjukat "b151a"
Nexenta Core 3.0.1	26	b134+	GNU userland
NexentaStor Community 3.0.1	26	b134+	18 TB -ig, web admin
NexentaStor közösség 3.1.0	28	b134+	GNU userland
NexentaStor Community 4.0	5000	b134+	18 TB -ig, web admin
NexentaStor Enterprise	28	b134 +	nem ingyenes, web admin
GNU/kFreeBSD "Squeeze" (nem támogatott)	14		"Zfsutils" csomag szükséges
GNU/kFreeBSD " Wheezy -9" (nem támogatott)	28		"Zfsutils" csomag szükséges
FreeBSD	5000
zfs-biztosíték 0.7.2	23		teljesítményproblémákkal küzdött; elhunyt
ZFS Linuxon 0.6.5.8	5000		A 0.6.0 kiadási jelölt POSIX réteggel rendelkezik
KQ Infotech ZFS Linuxon	28		elhunyt; kód LLNL-támogatott ZFS-be integrálva Linuxon
BeleniX 0.8b1	14	b111	kis méretű élő CD-forgalmazás; egyszer az OpenSolaris alapján
Schillix 0.7.2	28	b147	kis méretű élő CD-forgalmazás; mint SchilliX-ON 0.8.0 az OpenSolaris alapján
StormOS "jégeső"			egyszeri Nexenta Core 2.0+, Debian Linux alapú terjesztés ; helyébe a Dyson OS lépett
Jaris			Ja panese Sola ris elosztás; egyszer az OpenSolaris alapján
MilaX 0,5	20	b128a	kis méretű élő CD-forgalmazás; egyszer az OpenSolaris alapján
FreeNAS 8.0.2 / 8.2	15
FreeNAS 8.3.0	28		FreeBSD 8.3 alapján
FreeNAS 9.1.0+	5000		FreeBSD 9.1+ alapján
XigmaNAS 11.4.0.4/12.2.0.4	5000		FreeBSD 11.4/12.2 alapján
Korona 4.5.0	22	b134	KDE
EON NAS (v0.6)	22	b130	beágyazott NAS
EON NAS (v1.0beta)	28	b151a	beágyazott NAS
nap-it	28/5000	Illumos/Solaris	Tároló készülék; OpenIndiana (Hipster), OmniOS, Solaris 11, Linux (ZFS kezelés)
OmniOS CE	28/5000	illumos-OmniOS ág	minimális stabil/LTS tárolószerver -elosztás az Illumos alapján, közösségvezérelt
SmartOS	28/5000	Illumos b151+	minimális élő terjesztés az Illumos alapján (USB/CD rendszerindítás); felhő és hipervizor használat (KVM)
macOS 10.5, 10.6, 10.7, 10.8, 10.9	5000		MacZFS -en keresztül; az OpenZFS helyettesíti az OS X rendszeren
macOS 10.6, 10.7, 10.8	28		a ZEVO -n keresztül; az OpenZFS helyettesíti az OS X rendszeren
NetBSD	22
MidnightBSD	6
Proxmox VE	5000		natív támogatás 2014 óta [1] , pve.proxmox.com/wiki/ZFS_on_Linux
Ubuntu Linux 16.04 LTS+	5000		natív támogatás a telepíthető bináris modulon keresztül , wiki.ubuntu.com/ZFS
ZFSGuru 10.1.100	5000

Lásd még

• A fájlrendszerek összehasonlítása
• A fájlrendszerek listája
• Verziófájl -rendszer - A verziófájl -rendszerek listája

Megjegyzések

Hivatkozások

Bibliográfia

Külső linkek

• Villa Igen! Az illumosok felemelkedése és fejlődése - diavetítés, amely a Solaris történetének nagy részét tartalmazza, a Sun nyílt forráskódú döntése, a ZFS létrehozása, valamint az Oracle felvásárlása után lezárult események.
• A legjobb felhőalapú fájlrendszert a felhő létezése előtt hozták létre (archiválva 2018. december 15 -én)
• Az SVM tükrözés és a ZFS tükrözés összehasonlítása
• EON ZFS Storage (NAS) elosztás
• Teljes körű adatintegritás fájlrendszerekhez: ZFS esettanulmány
• ZFS - A Zettabyte fájlrendszer (archiválva: 2013. február 28.)
• ZFS és RAID-Z: Az Über-FS?
• ZFS: Az utolsó szó a fájlrendszerekben , Jeff Bonwick és Bill Moore (archiválva 2017. augusztus 29 -én)
• A ZFS szándéknapló (ZIL) megjelenítése , 2013. április, Aaron Toponce
• Az illumosok jellemzői, beleértve az OpenZFS -t
  • Előző wiki oldal további linkekkel: A ZFS használatának megkezdése , 2014. szeptember 15 (archiválva 2018. december 30 -án ), az illumos dokumentáció része