ZFS

Există diferite versiuni ale sistemului de fișiere ZFS și versiuni ale pool-ului ZFS ( zpool ), iar funcționalități diferite sunt disponibile în funcție de versiune. În noiembrie 2012, există 34 de versiuni ale pool-ului ZFS. Toate versiunile pool-ului sunt lansate inițial pentru Solaris .

Versiunea 2 a inclus suport pentru metadate replicate ( ditto blocks ) .  Datorită structurii arborescente a formatului de disc ZFS, erorile irecuperabile din metadatele pool-ului pot duce la imposibilitatea deschiderii pool-ului. Această caracteristică oferă replicare automată a metadatelor (până la trei copii ale fiecărui bloc ) indiferent de redundanța subiacentă la nivelul întregului grup . De exemplu, într-un pool cu ​​o singură oglindă, metadatele cele mai critice vor fi scrise de trei ori pe fiecare parte a oglinzii, pentru un total de șase copii. Acest lucru asigură că, dacă datele sunt pierdute din cauza corupției, toate datele din pool vor fi localizabile și pool-ul va fi sănătos.  

Versiunea 3 include suport pentru piese de rezervă și paritate duală RAID-Z (raidz2) ; versiunea 4 a introdus suport pentru menținerea istoricului pool-ului ZFS ( zpool history); versiunea 5 a adăugat suport pentru compresia din mers pentru seturile de date ZFS folosind metoda gzip ; versiunea 6 include suport pentru proprietatea bootfs (vă permite să comutați FS rădăcină a sistemului de operare bootabil printr-un atribut, în plus față de opțiunea bootloader).

Versiunea 7 a introdus suport pentru un „jurnal țintă” ( ZFS Intent Log , ZIL , lit. „intent log”), care oferă aplicațiilor posibilitatea de a ști că datele pe care le-au modificat sunt în stocare stabilă, la întoarcerea de la un apel de sistem . Jurnalul țintă păstrează înregistrări ale acestor apeluri de sistem, acestea sunt reluate dacă a existat o întrerupere de curent sau o eroare critică în care pool-ul principal nu a confirmat executarea lor. Când jurnalul țintă se află în afara pool-ului principal, acesta alocă blocuri care se conectează prin pool.

În versiunea 8, este implementată capacitatea de a delega sarcini administrative pentru gestionarea ZFS utilizatorilor obișnuiți; înainte de aceasta, numai administratorii aveau capacitatea de a gestiona ZFS.

În versiunea 9, pe lângă funcțiile de cotă și rezervare existente, a fost adăugată și alocarea de cote și rezerve, care nu include consumul de spațiu pe disc de către structurile de date imbricate, precum clonele și cotele ( zfs set refquota, zfs set refreservation). Rezervarea este stabilită automat atunci când volumul ZFS creat non-sparse ( non-sparse ) se potrivește cu dimensiunea partiției. Tot în versiunea 9 a fost adăugat suport pentru serverul CIFS .

Versiunea 10 a introdus capacitatea de a adăuga dispozitive la un pool ca dispozitive de stocare în cache pentru a oferi un strat suplimentar de stocare în cache între memoria principală și disc. Utilizarea dispozitivelor de stocare în cache îmbunătățește semnificativ performanța pentru citirile grele ale conținutului inordonat, mai ales static. În versiunea 12 a apărut suport pentru proprietățile instantanee, în versiunea 13 au devenit disponibile următoarele proprietăți instantanee: usedbysnapshots, usedbychildren, usedbyrefreservation, usedbydataset, în versiunea 14 sunt disponibile și proprietățile și passthrough-x, aclinheritîn versiunea 15 sunt incluse proprietățile userused, groupused, userquota, groupquota.

Versiunea 17 a introdus suport pentru RAID-Z cu paritate triplă . Versiunea 18 acceptă caracteristica de reținere a instantaneelor ​​ZFS . Începând cu versiunea 19, a devenit posibilă eliminarea unui dispozitiv atașat pentru stocarea jurnalelor; anterior, un astfel de dispozitiv nu putea fi eliminat. Versiunea 20 include algoritmul de compresie zle .

Versiunea 21 introduce deduplicarea (utilizarea majoră a zle). Începând cu versiunea 30 , este acceptată criptarea sistemului de fișiere , începând cu versiunea 32, este suportat un bloc de 1 MB, iar în versiunea 34, este implementată crearea de partajări de rețea cu moștenire între sistemele de fișiere.

Versiunea 37 a adăugat suport pentru algoritmul de compresie lz4 (mai eficient și mai rapid decât cele existente).

Modelul tranzacției utilizând copy-on-write

ZFS utilizează un model de tranzacție cu obiecte bazat pe mecanismul de copiere la scriere . Toți pointerii către blocuri din sistemul de fișiere conțin o sumă de control de 256 de biți în blocul țintă, care este verificată atunci când blocul este citit. Fie suma Fletcher , fie funcția hash criptografică SHA-256 poate fi utilizată ca sumă de control . [13] Alte sume de control pot fi alese pentru date. Blocurile de date care conțin date active (în acest moment) nu sunt niciodată suprascrise împreună; dimpotrivă, un bloc nou este alocat, datele modificate sunt scrise în el și apoi metadatele oricăror blocuri care se referă la el, astfel totul este realocat și scris. Pentru a reduce cheltuielile generale, acest proces grupează mai multe actualizări într-un grup de tranzacții și, dacă este necesar, înregistrează utilizarea în scriere sincronă.

Pool-ul ZFS menține un jurnal al ultimelor zeci de versiuni ale datelor pool (pentru ultimele minute, ore sau zile, în funcție de intensitatea modificării datelor), conceput pentru a restaura datele în cazul în care o eroare de sistem a adus pool într-o stare inoperabilă, incurabilă. Cu copiere la scriere, toate aceste versiuni ale datelor din jurnal sunt autonome, dar partajează date comune.

Instantanee și clone

Modelul copy-by-write din ZFS are un alt avantaj puternic: atunci când ZFS scrie date noi - în loc să elibereze blocuri care conțin date vechi - le poate salva prin crearea de instantanee ale sistemului de fișiere. Instantaneele în ZFS sunt create foarte rapid (cu excepția cazurilor rare de blocare lungă a pool-ului printr-o operație consumatoare de timp cu FS), deoarece toate datele din instantaneu sunt deja salvate; sunt, de asemenea, eficiente în spațiu, deoarece orice date neschimbate sunt partajate (partajate) între sistemul de fișiere și instantaneul său.

De asemenea, un instantaneu care poate fi scris („clonă”) poate fi creat din orice instantaneu, rezultând două sau mai multe sisteme de fișiere sau volume independente care împart un complex de blocuri pentru a reduce amprenta totală și a reduce timpul de creare a clonelor. De îndată ce se fac modificări oricărei clone a sistemului de fișiere, blocuri de date noi sunt create pentru aceasta, iar datele vechi rămân în toate celelalte clone.

Când este creată, o clonă este legată de instantaneul din care a fost creată. Acest instantaneu nu poate fi distrus atâta timp cât este referit de cel puțin 2 clone (inclusiv stocarea originală). Pentru a elimina această legătură, spațiul de stocare (sistem de fișiere sau volum) trebuie recreat, dar acest lucru se face cu ușurință utilizând transferul și puteți evita ocuparea spațiului suplimentar în pool dacă activați deduplicarea în timpul transferului și transferați spațiul de stocare în aceeasi piscina.

Instantaneele vă permit să accesați datele care se aflau în seif la momentul în care a fost realizat instantaneul ca același seif numai pentru citire, indiferent de seiful original, clonele sale și alte instantanee. De asemenea, vă permit să restaurați rapid și precis datele de stocare la o stare instantanee.

Instantaneele și clonele pot fi create recursiv pentru un arbore de sisteme de fișiere. Acest lucru evită necesitatea de a repeta comenzile și de a gestiona singur tranzacțiile, deoarece crearea recursive de instantanee este atomică.

Crearea de instantanee și clone (precum și noi sisteme de fișiere) poate fi dificilă din cauza limitărilor ZFS. Instantaneele și clonele nu pot fi create dacă numele a cel puțin unuia dintre ele depășește limita (și numele complet al instantaneului este mai lung decât numele complet al originalului cu cel puțin 2 caractere), dacă există un conflict de nume (esențial pentru crearea de instantanee recursive), dacă sunt depășite noi cote sau rezervele nu sunt fezabile (cotele și rezervele sunt moștenite de la original).

Pe baza unor instantanee, sunt implementate backup-uri incrementale de stocare. Folosind redirecționarea instantaneelor, puteți recrea aceeași secvență de instantanee în orice pool ZFS. După crearea unor noi instantanee ale originalului, transferul incremental de instantanee recreează aceleași date actualizate în copiere sau clonă, cu excepția cazului în care există un conflict de actualizare. De asemenea, instantaneele vă informează ce fișiere au fost modificate, create, șterse și redenumite între instantanee.

Partiționare dinamică

Partiționarea dinamică a tuturor dispozitivelor la debit maxim înseamnă că dispozitivele suplimentare sunt incluse în zpool, canalele mai largi sunt extinse automat pentru a include utilizarea tuturor discurilor din pool, ceea ce echilibrează sarcina de scriere.

Diverse dimensiuni de bloc

ZFS folosește o dimensiune variabilă a blocului de până la 1 megaoctet (de la versiunea pool 32, obișnuia să fie de până la 128 de kiloocteți). În prezent, administratorului i se permite să seteze dimensiunea maximă a blocurilor utilizate, dar unele lucrări vor eșua (sau eșuează) dacă sunt folosite blocuri prea mari. Setările automate de performanță corespund privilegiilor.

Dacă compresia este activată, sunt utilizate dimensiuni variabile ale blocurilor. Dacă un bloc a fost comprimat, acesta se poate îmbina într-un bloc mai mic, ceea ce înseamnă că este utilizat mai puțin spațiu pe disc și debitul (Intrare/Ieșire) este crescut (cu prețul utilizării CPU și RAM crescute pentru operațiunile de compresie și decompresie).

Pool-ul ZFS acceptă, de asemenea, diferite dimensiuni de sector de dispozitiv și selectează automat cea mai mare dimensiune a blocului dintre dispozitivele specificate când a fost creat pool-ul (după aceea, dimensiunea blocului pool-ului nu poate fi modificată). Dimensiunile de 512 octeți, 4 KiB (4K) sunt acceptate stabil. Dimensiunile mari ale blocurilor sunt, de asemenea, acceptate, dar este posibil ca sistemul de operare să nu funcționeze stabil.

Controlul integrității datelor de la capăt la capăt

Controlul integrității end-to-end se referă la scrierea unei sume de control pe disc pentru fiecare bloc de date, iar suma de control și datele sunt distanțate în mod special cât mai departe posibil una de cealaltă pentru a reduce probabilitatea deteriorării articulațiilor. Dacă există mai multe dispozitive în pool, atunci pentru datele aflate pe unul dintre ele, suma de control va fi scrisă pe celălalt. Sumele de control sunt calculate nu numai pentru date, ci și pentru metadate și se dovedește că pool-ul are întotdeauna o sumă de control pentru fiecare bloc de informații.

La citirea oricărui bloc, suma de control este calculată și rezultatul este comparat cu suma de control stocată pe disc. În caz de discrepanță, eroarea este imediat detectată. Desigur, dacă nu a fost planificată în prealabil o redundanță în pool (nici RAID-Z, nici altfel), atunci eroarea nu poate fi corectată, dar datele corupte nu vor fi prezentate ca adevărate.

Scopul integrității datelor de la capăt la capăt este de a preveni corupția nedetectată a datelor din cauza defecțiunilor hardware sau firmware-ului unității sau controlerului. Deși probabilitatea unui astfel de eveniment pare scăzută, unele studii arată că este destul de semnificativă pentru organizațiile de orice dimensiune [14] .

Programele care citesc sau scriu date trebuie să accepte aceste caracteristici (posibilitatea eșecului de a citi un singur bloc al unui fișier, posibilitatea ca pool-ul să intre într-o stare de așteptare pentru recuperarea stocării cu I/O suspendat pentru o perioadă nedeterminată).

Crearea unui sistem de fișiere ușor

În ZFS, manipularea unui sistem de fișiere într-un pool este mai ușoară decât cantitatea de manipulare din sistemele de fișiere tradiționale; timpul și efortul necesar pentru a crea sau modifica un sistem de fișiere ZFS seamănă mai mult cu cantitatea de muncă implicată cu un director nou decât cu manipularea partițiilor în alte tehnologii.

Caracteristici suplimentare

Caracteristicile suplimentare includ o funcție pentru a seta o anumită prioritate I/O cu o perioadă de programare, suport pentru mai multe fire independente cu detectarea automată preventivă a lungimii și pasului, curățare și corecție inteligentă [15] , încărcare și partajare a discurilor într-un pool [16] , redare multiplă a metadatelor [ 17] , suport pentru mecanismul de copiere la scriere , abilitatea de a selecta un sistem de fișiere de pornire în încărcătorul sistemului de operare , instalarea sistemului principal de fișiere de boot, crearea mai multor sisteme de fișiere rădăcină, dintre care unul (cu toți copiii) vor fi utilizate la încărcarea sistemului de operare , capacitatea de a integra software și actualizări ale sistemului de operare cu crearea de instantanee și clone ale sistemelor de fișiere în care sunt stocate programe și utilizarea acestor instantanee pentru a restaura cu ușurință o versiune anterioară și clonele pentru a crea un sistem multiboot cu posibilitatea de a porni diferite configurații sau versiuni de sistem de operare ( Solaris este actualizat implicit), o opțiune pentru limitarea numelor de fișiere la text valid în UTF-8 în forma normală selectată, o opțiune pentru a nu sensibiliza majusculele caracterelor din numele fișierelor.

Gestionarea memoriei cache

ZFS introduce, de asemenea, înlocuirea adaptivă a memoriei cache ( ARC ), o nouă metodă de gestionare a memoriei cache în locul paginilor virtuale tradiționale din cache în memorie Solaris.

Endianness adaptiv

Array-urile și ZFS-ul configurat pe ele pot fi transferate între diferite platforme, chiar dacă au o îndianitate diferită. Formatul bloc ZFS permite detectarea automată și reordonarea octeților din mers atunci când metadatele sunt citite.

În același timp, ordinea diferită a octeților pe diferite sisteme nu afectează în niciun fel aplicațiile, fișierele pentru aceștia rămânând o simplă secvență de octeți. Astfel, aplicațiile sunt responsabile pentru formatul independent (platformă) deja în fișierele în sine.

Atribute pool

Atributele pool-ului sunt o modalitate de a controla caracteristicile și setările unui pool. Au tipuri speciale și restricții de scriere. Acestea indică dacă pool-ul este inscriptibil sau citibil, dacă deduplicarea datelor este activată, FS pentru încărcarea OS în mod implicit, o rădăcină de montare alternativă, caracteristicile pool-ului și multe altele.

Atributele sistemului de depozit de date

Atributele sistemului de depozit sunt o modalitate de a gestiona capabilitățile și setările depozitelor. Au tipuri speciale și restricții de scriere. Acestea specifică setările pentru criptare, compresie, sume de control, deduplicare, backup, cache, dimensiunea blocurilor de stocare a datelor din anumite stocări. Ele indică, de asemenea, dimensiunea volumelor, punctele de montare FS, disponibilitatea stocărilor individuale pentru scriere, apartenența depozitelor la zone, mandate, rezerve, cote, setări pentru crearea automată a partajărilor de rețea (NFS, SMB), drepturi de acces la acestea și Mai Mult. Aceste atribute specifică caracteristicile bolților. Aceste atribute facilitează gestionarea funcțiilor legate de FS care au fost efectuate anterior manual (de exemplu, configurarea montarii mai multor sisteme de fișiere suplimentare, crearea de partajări de rețea).

Unele dintre atributele sistemului sunt moștenite de depozitele copil; ca urmare, atributele sunt aplicate imediat și depozitelor copil. Atributele pentru controlul compresiei, deduplicarii, sumelor de verificare a datelor și altele asemenea se aplică numai datelor nou scrise. Pentru a le aplica tuturor datelor, datele trebuie suprascrise (acest lucru se face cu ușurință prin trimiterea de instantanee la același pool cu ​​recrearea stocărilor).

Atribute personalizate ale magazinului de date

Fiecărui depozit de date (FS, volum, instantaneu etc.) i se pot atribui atribute personalizate. Atributele utilizatorului diferă de atributele sistemului în numele lor. Pentru atributele personalizate, puteți utiliza orice nume (de la 1 la 2¹⁰ octeți), dar este recomandat să folosiți nume care conțin două puncte (pentru a evita conflictele cu atributele sistemului), numele dvs. de domeniu înainte de aceste două puncte (pentru a evita cu alți utilizatori) , numele atributului după două puncte. Atributele personalizate sunt moștenite de magazinele pentru copii.

Datorită dezvoltării ramificate a noilor caracteristici în diferite sisteme de operare, mai multe dintre aceste atribute sunt folosite ca atribute de sistem noi.

Atributele personalizate sunt folosite de utilizatori și de programele de sine stătătoare (de exemplu, programul de creare automată și backup cu glisare de timp).

Atributele sistemului de fișiere

Pentru fișierele de orice tip, poate fi specificată valoarea mai multor atribute de sistem. [18] Aceste atribute vă permit să controlați acțiunile asupra fișierului. Atributele de fișiere extinse au aceleași atribute de sistem.

Pe lângă atributele care stochează datele de creare, ultimul acces, ultima modificare, ultima modificare a metadatelor, există atribute [19] :

Atribute extinse

Puteți crea atribute extinse pentru fiecare fișier de orice tip. Atributul extins este o matrice numită de octeți, la fel ca un fișier obișnuit. Atributelor extinse, cum ar fi fișierele obișnuite, li se pot atribui propriile permisiuni și atribute de sistem. Spre deosebire de un fișier obișnuit, atributele extinse, linkurile hard nu pot fi create pentru atributele extinse. Atributele extinse ale fișierelor au capacitatea de a fi tratate ca fișiere normale într-o măsură limitată. Pentru a face acest lucru, este creat un folder fără nume pentru fiecare fișier (la momentul creării primului atribut extins), în care sunt disponibile fișiere obișnuite corespunzătoare atributelor extinse ale acestui fișier. Pe Solaris, acest folder poate fi accesat utilizând utilitarul runat[21] .

Delegarea de autoritate către utilizatori

Gestionarea seifurilor individuale poate fi delegată utilizatorilor. Pentru a face acest lucru, ZFS a alocat puteri care pot fi delegate (crearea de stocări, instantanee, ștergerea lor, montare, comparare, redirecționare și multe altele). Permisiunile sunt delegate pentru seifurile selectate în același mod ca și atribuirea de atribute și se extind la seifurile secundare.

Reținerea datelor și backup

Datorită principiului „ copy-on-write ” ,  datele din ZFS sunt întotdeauna într-o stare consecventă, fișierul nu poate fi pierdut în momentul suprascrierii [6] .

Atunci când se utilizează volume cu redundanță (volume RAIDZ), siguranța datelor este asigurată în cazul defecțiunii suportului fizic [6] [22] , în timp ce RAIDZ este eficient pentru stocarea pe termen relativ lung a fișierelor mari, mai ales când se stabilește dimensiunea blocului corespunzătoare fișiere, iar cu rescrierea frecventă și la plasarea fișierelor de dimensiuni mici, există o sarcină crescută asupra procesorului și a subsistemului de disc [6] .

Restricții

• Implementarea ZFS de către Solaris 10 nu are criptare transparentă, așa cum se găsește în Solaris 11 și NTFS , deși există o implementare a acesteia ca parte a proiectului OpenSolaris [23] .
• ZFS nu acceptă alocarea de cote pe utilizator sau pe grup. În schimb, puteți crea rapid FS pentru utilizatori, fiecare dintre acestea având propria dimensiune. Ca atare, nu există o soluție practică de cotă pentru sistemele de fișiere partajate de diferiți utilizatori (de exemplu, un proiect de echipă de dezvoltare) în care datele pot fi partajate pentru fiecare utilizator, dar aceasta poate fi implementată deasupra stivei ZFS .
• Extinderea stocării se realizează de obicei prin adăugarea unui grup de discuri, cum ar fi un vdev (stripe, RAID-Z , RAID-Z2 sau mirror ). Noile date vor folosi în mod dinamic toate vdev-urile disponibile. O altă modalitate de a crește spațiul pe disc este înlocuirea alternativă a discurilor fizice cu altele mai mari, cu așteptarea, după fiecare astfel de operațiune, până când ZFS se vindeca singur . Timpul de tratament depinde de cantitatea de informații stocate și nu de dimensiunea discului. Dacă se creează un instantaneu în timpul tratamentului  , acesta va reporni procesul de tratament. Trebuie remarcat faptul că înlocuirea discurilor fără pierdere de date este posibilă numai într-unul dintre modurile de funcționare a pool-ului care o permit.
• În prezent, nu este posibil să se reducă numărul de vdev-uri fără a reduce dimensiunea pool-ului. Cu toate acestea, echipa de dezvoltare ZFS lucrează la această problemă. De la lansarea Solaris 10 08/11 (Actualizare 10), aceasta încă nu a fost implementată.
• De asemenea, nu este posibil să adăugați o unitate nouă la o matrice RAID-Z sau RAID-Z2 (vdevs). Această caracteristică este dificil de implementat. Cu toate acestea, puteți crea un RAIDZ vdev și îl puteți adăuga la zpool .
• Nu puteți amesteca tipuri de vdev într-un zpool. De exemplu, dacă aveți un pool ZFS eliminat care conține discuri pe un SAN , nu veți putea adăuga discuri locale ca vdev în oglindă.
• O reconfigurare completă a stocării datelor necesită salvarea datelor pe medii externe (în afara ZFS), distrugerea pool-urilor și crearea de noi pool-uri conform noilor reguli. Dar, în cele mai multe cazuri, puteți scăpa cu transferul de date din pool-ul vechi în cel nou folosind ZFS, păstrând toate sau datele și atributele dorite (fără a stoca în afara ZFS). Redirecționarea nu va ajuta în cazul activării sau dezactivării criptării, modificării restricțiilor privind numele fișierului, dezactivarea controlului de acces obligatoriu, modificarea dimensiunii blocului de disc și alte operațiuni rare.
• ZFS nu este în mod inerent un sistem de fișiere în cluster , distribuit sau paralel și nu oferă acces simultan la date de la gazde diferite. ZFS este un sistem de fișiere local.
• În implementarea ZFS de către Solaris 11, nu puteți modifica tipul vdev în zpool. De exemplu, dacă aveți un pool ZFS care conține discuri (dispozitive bloc), nu veți putea copia conținutul discurilor în fișiere obișnuite și nu veți putea importa pool-ul din aceste fișiere și invers - transferați pool-ul din fișierele obișnuite în discuri.
• Ștergerea unei cantități mari de date este o operațiune de blocare lentă (în versiunea pool 37 și anterioară), de exemplu, ștergerea unui sistem de fișiere fragmentat de 100 GiB poate dura mai mult de un minut și blochează obținerea unei liste de sisteme de fișiere și a altor sisteme de fișiere. acțiuni în același pool .
• Nu există nicio modalitate de a controla recuperarea pool-ului după restaurarea accesului la diferite copii ale pool-ului în oglindă. Sistemul decide singur cum să dezinfecteze piscina, chiar dacă modificările au fost făcute independent la diferite copii ale piscinei (acest lucru este permis).
• O piscină grav deteriorată nu poate fi reparată și trebuie recreată. Cu toate acestea, în multe cazuri, datele utilizatorului pot fi preluate din pool-ul corupt, importându-l pentru citire.
• O anumită corupție incurabilă a pool-ului în datele de sistem nu are ca rezultat coruperea datelor utilizatorului sau blocarea modificărilor pool-ului. Cu aceste avarii, piscina extern continuă să funcționeze normal mult timp și nu avertizează asupra necesității remedierii acesteia. Dar dacă nu este corectat, va pierde în cele din urmă datele utilizatorului și va ajunge într-o stare irecuperabilă sau chiar ilizibilă. Capacitatea de a detecta astfel de probleme și de a le remedia automat (dacă este posibil) în timp util nu este încorporată în ZFS și necesită o configurare separată.

Platforme

ZFS face parte din sistemul de operare Solaris și este disponibil atât pentru platformele SPARC , cât și pentru x86 . Deoarece codul ZFS este open source (licență CDDL), porturile către alte sisteme de operare și platforme pot fi produse fără implicarea Oracle.

OpenSolaris

OpenSolaris 2008.05 folosește ZFS ca sistem de fișiere implicit.

Nexenta OS  este un sistem de operare cu un mediu GNU construit pe nucleul OpenSolaris și pe mediul său de rulare, suportul ZFS a fost inclus în versiunea alpha1 a nucleului. Mai recent, Nexenta Systems a introdus NexentaStor  , un sistem de stocare de rețea activat ZFS care oferă capabilități NAS / SAN / iSCSI și se bazează pe Nexenta OS. NexentaStor include o interfață grafică care simplifică procesul de utilizare a ZFS. Pe 2 decembrie 2008, NexentaStor 1.1 a fost lansat. A actualizat nucleul OpenSolaris, a îmbunătățit integrarea cu CIFS/AD, a adăugat mai multe plugin-uri și a remediat unele erori. Există două ediții de NexentaStor: o ediție comercială Enterprise și o ediție gratuită pentru comunitate, cu o limită maximă a capacității de stocare de 18 TB. Din august 2012, versiunea actuală a software-ului este 3.1.3.

Linux