close

ZFS

Přejít na navigaci Přejít na hledání
ZFS
Vývojář Oracle (dříve Sun Microsystems ) , vývojáři fork OpenZFS
Souborový systém ZFS - Zettabyte File System
Datum podání listopad 2005 ( OpenSolaris )
Struktura
Obsah složky Rozšiřitelná hash tabulka
Omezení
Maximální velikost souboru 16  exbibytů
Maximální počet souborů 248 _
Maximální délka souboru 255 bajtů
Maximální velikost svazku 256  zebibajtů
Platné znaky v názvech žádné kódování nebo UTF-8 (volitelné)
Schopnosti
Přesnost ukládání data 1 ns [1]
Toky metadat Ano (s názvem Rozšířené atributy )
Atributy POSIX , další
Přístupová práva POSIX
Komprese pozadí Ano
Šifrování na pozadí Od bazénové verze 30
OS podporován Solaris , OpenSolaris , FreeBSD , Linux (přes FUSE nebo samostatný modul jádra ( ZFS na Linuxu )), Apple Mac OS X 10.5 , Windows ( ZFSin )

ZFS (Zettabyte File System) je souborový systém Merkle tree copy-on-write vytvořený společností Sun Microsystems v letech 2004–2005 pro operační systém Solaris . Tento souborový systém podporuje velká množství dat, kombinuje koncepty souborového systému, polí RAID , správce logických disků (svazků) , principy odlehčených souborových systémů a poskytuje jednoduchou správu objemů úložiště dat. V době, kdy byl ZFS vytvořen, byla jeho struktura rozložení dat inovativní. Existují otevřené implementace ZFS, zejména OpenZFS je licencován pod CDDL ( Common Development and Distribution License ). Kvůli licenčním omezením je podpora ZFS na GNU/Linux omezená, což není případ souborového systému Btrfs podobného ZFS . ZFS je v současné době v aktivním vývoji.  

Hlavními výhodami ZFS je jeho úplná kontrola nad fyzickými médii a logickými svazky a neustálé udržování konzistence souborového systému. ZFS, který pracuje na různých úrovních abstrakce dat, je schopen k nim poskytovat vysokorychlostní přístup, řídit jejich integritu a minimalizovat fragmentaci dat . ZFS je vysoce konfigurovatelný, umožňuje měnit množství místa na disku v procesu a nastavovat různé velikosti datových bloků pro různé aplikace a poskytuje paralelní operace čtení a zápisu.

Historie

ZFS byl navržen a postaven ve společnosti Sun Microsystems týmem vedeným Jeffem Bonwickem a oznámen  14. září 2004 [2] . Zdrojový kód pro finální verzi byl integrován do hlavní větve Solaris 31. října 2005 [3] .

ZFS bylo součástí OpenSolaris build 27 , vydaného 16. listopadu 2005. Sun uvedl, že ZFS byl integrován do aktualizace 6/06 pro Solaris 10 v červnu 2006, jeden rok po otevření komunity OpenSolaris [4] .

ZFS se původně jmenoval „ Zettabyte File System “, ale později se tento název vyvinul v jednoduchou zkratku [5] .

ZFS byl vydán pod komerční licencí jako součást operačního systému Solaris, poté SUN Microsystems open-source ZFS v projektu OpenSolaris pod CDDL. Po akvizici SUN Microsystems společností Oracle byl kód opět uzavřen, ale v té době již byl ZFS zahrnut do FreeBSD a dalších open source projektů, které se vyvíjely nezávisle a vyměňovaly si zdrojové kódy prostřednictvím „backportů“ ( angl.  backports ) [6] .

V roce 2013 byl spuštěn projekt OpenZFS [en] [7] [8] , který přebírá nové funkce a opravy z Illumos a distribuuje na všechny porty na jiné platformy a naopak [9] .

Specifičnost

Maximální příležitosti

ZFS - 128-bit[10] souborový systém, který umožňuje uložit 18,4 × 10 18krát více dat než všechny známé 64bitové systémy. ZFS je navržen tak, aby jeho omezení byla natolik nedosažitelná, že se s nimi v dohledné době v praxi nesetkáme [11] .

Některé teoretické limity v ZFS:

  • 2 48  - počet snímků v libovolném systému souborů (2 × 10 14 );
  • 2 48  je počet souborů v libovolném systému souborů (2 × 10 14 );
  • 256 zettabajtů ( 1021 bajtů )  - maximální velikost souborového systému;
  • 16 exbibajtů (2 64 bajtů ) - maximální velikost jednoho souboru;
  • 16 exbibajtů (2 64 bajtů ) - maximální velikost libovolného atributu [12] ;
  • 3×10 23 petabajtů  - maximální velikost libovolného úložiště ( zpool );
  • 2 56  - počet atributů souboru (ve skutečnosti omezený na 2 48 pro počet souborů v systému souborů ZFS);
  • 2 56  - počet souborů v adresáři (ve skutečnosti omezen na 2 48 pro počet souborů v systému souborů ZFS);
  • 2 64  - počet zařízení v libovolném fondu;
  • 2 64  - počet bazénů v systému;
  • 264 je počet souborových  systémů v jednom fondu;
  • 255 bajtů  - maximální délka názvu souboru (ne celý název, ale vzhledem k nadřazené složce);
  • 255 bajtů  je maximální délka celého názvu datového úložiště (systém souborů, svazek, snímek, sdílená položka atd.).

Zároveň nástroje pro správu souborového systému ukládají další omezení.

Skladovací fondy

Na rozdíl od tradičních souborových systémů, které jsou umístěny na jednom zařízení, a proto vyžadují správce svazků, pokud jsou používány na více než jednom zařízení, je ZFS postaven na virtuálních úložných fondech nazývaných zpools . Fond je vytvořen z virtuálních zařízení ( vdevs ), z nichž každé je buď fyzické zařízení, nebo zrcadlo ( RAID 1) jednoho nebo více zařízení, nebo ( RAID Z) skupina dvou nebo více zařízení. Kapacita všech vdev je pak dostupná všem souborovým systémům v zpoolu .

Kvótu lze nastavit tak, aby omezila prostor dostupný pro konkrétní souborový systém nebo svazek . Kromě toho je možné použít rezervaci disku (limit) – tím je zajištěno, že vždy bude nějaké volné místo pro konkrétní souborový systém nebo svazek.

Verze fondu ZFS

Existují různé verze systému souborů ZFS a verze fondu ZFS ( zpool ) a v závislosti na verzi jsou k dispozici různé funkce. K listopadu 2012 existuje 34 verzí fondu ZFS. Všechny verze fondu jsou původně vydány pro Solaris .

Verze 2 obsahovala podporu pro replikovaná metadata ( stejně jako bloky ) .  Kvůli stromové struktuře formátu disku ZFS mohou neopravitelné chyby v metadatech fondu způsobit, že fond nebude možné otevřít. Tato funkce poskytuje automatickou replikaci metadat (až tři kopie každého bloku ) bez ohledu na základní redundanci celého fondu . Například ve fondu s jedním zrcadlem budou nejkritičtější metadata zapsána třikrát na každou stranu zrcadla, celkem tedy šest kopií. To zajišťuje, že pokud dojde ke ztrátě dat v důsledku poškození, všechna data ve fondu budou lokalizovatelná a fond bude v pořádku.  

Verze 3 obsahuje podporu pro horké náhradní díly a duální paritní RAID-Z (raidz2); verze 4 zavedla podporu pro udržování historie fondu ZFS ( zpool history); verze 5 přidala podporu pro průběžnou kompresi datových sad ZFS pomocí metody gzip ; verze 6 obsahuje podporu pro vlastnost bootfs (umožňuje přepínat kořenový FS zaváděcího OS pomocí atributu, kromě volby bootloaderu).

Verze 7 zavedla podporu pro „target log“ ( ZFS Intent Log , ZIL , lit. „intent log“), který aplikacím poskytuje možnost vědět, že data, která upravili, jsou ve stabilním úložišti, po návratu ze systémového volání. . Cílový protokol uchovává záznamy o těchto systémových voláních, která se přehrají, pokud došlo k výpadku napájení nebo kritické chybě, kdy hlavní fond nepotvrdil jejich provedení. Když se cílový žurnál nachází mimo hlavní fond, přiděluje bloky, které procházejí fondem.

Ve verzi 8 je implementována možnost delegovat administrativní úkoly pro správu ZFS na běžné uživatele, předtím měli možnost spravovat ZFS pouze správci.

Ve verzi 9 bylo kromě stávajících funkcí kvót a rezervací přidáno přidělování kvót a rezerv, které nezahrnuje spotřebu místa na disku vnořenými datovými strukturami, jako jsou klony a kvóty ( zfs set refquota, zfs set refreservation). Rezervace se automaticky vytvoří, když vytvořený neřídký ( neřídký ) svazek ZFS odpovídá velikosti oddílu. Také ve verzi 9 byla přidána podpora pro server CIFS .

Verze 10 zavedla možnost přidávat zařízení do fondu jako zařízení pro ukládání do mezipaměti a poskytovat tak další vrstvu mezipaměti mezi hlavní pamětí a diskem. Použití zařízení pro ukládání do mezipaměti výrazně zlepšuje výkon při náročném čtení neuspořádaného, ​​většinou statického obsahu. Ve verzi 12 se objevila podpora vlastností snímku, ve verzi 13 byly k dispozici následující vlastnosti snímku: usedbysnapshots, usedbychildren, usedbyrefreservation, usedbydataset, ve verzi 14 jsou k dispozici také vlastnosti a passthrough-x, aclinheritve verzi 15 jsou zahrnuty vlastnosti userused, groupused, userquota, groupquota.

Verze 17 zavedla podporu pro trojitou paritu RAID-Z . Verze 18 podporuje funkci ZFS snapshot holds . Počínaje verzí 19 bylo možné odebrat připojené zařízení pro ukládání protokolů, dříve nebylo možné takové zařízení odebrat. Verze 20 obsahuje algoritmus komprese zle .

Verze 21 zavádí deduplikaci (hlavní použití zle). Počínaje verzí 30 je podporováno šifrování souborového systému , počínaje verzí 32 je podporován 1 MB blok a ve verzi 34 je implementováno vytváření síťových sdílených složek s dědičností mezi systémy souborů.

Verze 37 přidala podporu pro kompresní algoritmus lz4 (efektivnější a rychlejší než stávající).

Transakční model využívající kopírování při zápisu

ZFS používá objektový transakční model založený na mechanismu kopírování při zápisu . Všechny ukazatele na bloky v systému souborů obsahují 256bitový kontrolní součet v cílovém bloku, který se kontroluje při čtení bloku. Jako kontrolní součet lze použít buď Fletcherův součet , nebo kryptografickou hašovací funkci SHA-256 . [13] Pro data lze zvolit jiné kontrolní součty. Datové bloky obsahující aktivní (momentálně) data se nikdy nepřepisují společně; naopak je alokován nový blok, do něj se zapisují změněná data a následně metadata všech bloků, které na něj odkazují, tím se vše přerozdělí a zapíše. Pro snížení režie tento proces seskupuje více aktualizací do skupiny transakcí a v případě potřeby zaznamenává využití při synchronních zápisech.

Fond ZFS uchovává protokol posledních několika desítek verzí dat fondu (za posledních několik minut, hodin nebo dní, v závislosti na intenzitě změny dat), určený k obnovení dat v případě, že systémová chyba přinesla bazén do nefunkčního, nevyléčitelného stavu. Při kopírování při zápisu jsou všechny tyto verze dat v protokolu samostatné, ale sdílejí společná data.

Snímky a klony

Model kopírování po zápisu v ZFS má další silnou výhodu: když ZFS zapisuje nová data – namísto uvolňování bloků obsahujících stará data – může je uložit vytvořením snímků systému souborů. Snapshoty v ZFS jsou vytvářeny velmi rychle (s výjimkou vzácných případů dlouhého blokování fondu časově náročnou operací s FS), protože všechna data ve snapshotu jsou již uložena; jsou také prostorově úsporné, protože veškerá nezměněná data jsou sdílena (sdílena) mezi souborovým systémem a jeho snímkem.

Z libovolného snímku lze také vytvořit zapisovatelný snímek („klon“), což má za následek dva nebo více nezávislých souborových systémů nebo svazků, které sdílejí komplex bloků, aby se snížila celková stopa a zkrátila se doba vytváření klonu. Jakmile jsou provedeny změny v jakémkoli klonu souborového systému, vytvoří se pro něj bloky nových dat a stará data zůstanou ve všech ostatních klonech.

Po vytvoření je klon propojen se snímkem, ze kterého byl vytvořen. Tento snímek nelze zničit, pokud na něj odkazují alespoň 2 klony (včetně původního úložiště). Chcete-li toto propojení odstranit, je třeba úložiště (systém souborů nebo svazek) znovu vytvořit, ale to lze snadno provést pomocí přenosu a můžete se vyhnout zabírání dalšího místa ve fondu, pokud během přenosu povolíte deduplikaci a přenesete úložiště v rámci stejný bazén.

Snímky umožňují přístup k datům, která byla v úložišti v době, kdy byl snímek pořízen, jako stejný vault pouze pro čtení, bez ohledu na původní vault, jeho klony a další snímky. Umožňují také rychle a přesně obnovit data úložiště do stavu snímku.

Snímky a klony lze vytvářet rekurzivně pro strom souborových systémů. Tím se vyhnete nutnosti opakovat příkazy a spravovat transakce sami, protože vytváření rekurzivních snímků je atomické.

Vytváření snímků a klonů (stejně jako nových souborových systémů) může být obtížné kvůli omezením ZFS. Snímky a klony nelze vytvořit, pokud název alespoň jednoho z nich překročí limit (a celý název snímku je delší než celý název originálu alespoň o 2 znaky), pokud dojde ke konfliktu názvů (nezbytné pro vytváření rekurzivního snímku), pokud jsou překročeny nové kvóty nebo rezervy nejsou proveditelné (kvóty a rezervy se dědí z původních).

Na základě snímků jsou implementovány přírůstkové zálohy úložiště. Pomocí předávání snímků můžete znovu vytvořit stejnou sekvenci snímků v libovolném fondu ZFS. Po vytvoření nových snímků originálu, přírůstkový přenos snímků znovu vytvoří stejná aktualizovaná data v kopii nebo klonu, pokud nedojde ke konfliktu aktualizací. Snímky také umožňují vědět, které soubory byly mezi snímky změněny, vytvořeny, odstraněny a přejmenovány.

Dynamické dělení

Dynamické rozdělování všech zařízení na maximální propustnost znamená, že do zpoolu jsou zahrnuta další zařízení, širší kanály se automaticky rozšiřují tak, aby zahrnovaly použití všech disků ve fondu, čímž se vyrovnává zátěž při zápisu.

Různé velikosti bloků

ZFS používá variabilní velikost bloku až 1 megabajt (od verze poolu 32 to bývalo až 128 kilobajtů). V současné době může administrátor nastavit maximální použitou velikost bloku, ale některé práce selžou (nebo selžou), pokud jsou použity příliš velké bloky. Automatické nastavení výkonu odpovídá oprávněním.

Pokud je povolena komprese, použijí se proměnné velikosti bloků. Pokud byl blok zkomprimován, může se sloučit do menšího bloku, což znamená, že se použije méně místa na disku a zvýší se propustnost (vstup/výstup) (za cenu zvýšeného využití CPU a RAM pro operace komprese a dekomprese).

Fond ZFS také podporuje různé velikosti sektorů zařízení a automaticky vybírá největší velikost bloku ze zařízení zadaných při vytvoření fondu (potom již nelze velikost bloku fondu změnit). Velikosti 512 bajtů, 4 KiB (4K) jsou stabilně podporovány. Podporovány jsou také velké velikosti bloků, ale OS nemusí fungovat stabilně.

End-to-End kontrola integrity dat

End-to-end kontrola integrity se týká zápisu kontrolního součtu na disk pro každý datový blok, přičemž kontrolní součet a data jsou od sebe speciálně rozmístěna co nejdále, aby se snížila pravděpodobnost jejich společného poškození. Pokud je ve fondu více zařízení, pak pro data umístěná na jednom z nich se kontrolní součet zapíše na druhé. Kontrolní součty se počítají nejen pro data, ale také pro metadata a ukazuje se, že fond má vždy kontrolní součet pro každý blok informací.

Při čtení libovolného bloku se vypočítá jeho kontrolní součet a výsledek se porovná s kontrolním součtem uloženým na disku. V případě nesrovnalostí je chyba okamžitě detekována. Samozřejmě, pokud nebyla předem naplánována žádná redundance ve fondu (ani RAID-Z, ani jinak), pak chybu nelze opravit, ale poškozená data nebudou prezentována jako pravdivá.

Smyslem integrity dat End-to-End je zabránit nezjištěnému poškození dat v důsledku selhání hardwaru nebo firmwaru disku nebo řadiče. Ačkoli se pravděpodobnost takové události zdá nízká, některé studie ukazují, že je poměrně významná pro organizace jakékoli velikosti [14] .

Programy, které čtou nebo zapisují data, musí tyto funkce podporovat (možnost selhání čtení jednoho bloku souboru, možnost přechodu fondu do stavu čekání na obnovu úložiště s pozastavením I/O na neurčitou dobu).

Vytvoření odlehčeného systému souborů

V ZFS je manipulace se souborovým systémem ve fondu jednodušší než manipulace s tradičními souborovými systémy; čas a úsilí potřebné k vytvoření nebo úpravě souborového systému ZFS se více podobají množství práce spojené s novým adresářem než manipulací s oddíly v jiných technologiích.

Další funkce

Mezi další funkce patří funkce pro nastavení konkrétní I/O priority s plánovacím obdobím, podpora více nezávislých vláken s preemptivní automatickou detekcí délky a rozteče, inteligentní čištění a korekce [15] , načítání a sdílení disků ve fondu [16] , vícenásobné přehrávání metadat [ 17] , podpora mechanismu copy-on-write , možnost vybrat si spouštěcí souborový systém v zavaděči OS , nainstalovat hlavní spouštěcí souborový systém, vytvořit několik kořenových souborových systémů, z nichž jeden (s všechny děti) se využije při načítání operačního systému , možnost integrovat aktualizace softwaru a operačního systému s vytvářením snímků a klonů souborových systémů, ve kterých jsou programy uloženy, a použití těchto snímků pro snadné obnovení předchozí verze a klonů vytvořit multibootový systém s možností zavádění různých konfigurací nebo verzí OS ( Solaris je ve výchozím nastavení aktualizován), možnost pro omezení názvů souborů na platný text v UTF-8 ve vybrané normální formě, možnost necitlivosti znaků v názvech souborů.

Správa mezipaměti

ZFS také zavádí adaptivní náhradu mezipaměti ( ARC ), novou metodu správy mezipaměti namísto tradičních virtuálních stránek mezipaměti Solaris.

Adaptivní endianness

Pole a na nich nakonfigurované ZFS lze přenášet mezi různými platformami, i když mají různou endianitu. Formát bloku ZFS umožňuje automatickou detekci a změnu pořadí bajtů za běhu při čtení metadat.

Rozdílné pořadí bajtů na různých systémech přitom nijak neovlivňuje aplikace, soubory pro ně zůstávají jednoduchou sekvencí bajtů. Aplikace jsou tedy zodpovědné za nezávislý (platformní) formát již v samotných souborech.

Atributy fondu

Atributy fondu představují způsob, jak ovládat funkce a nastavení fondu. Mají speciální typy a omezení zápisu. Označují, zda je fond zapisovatelný nebo čitelný, zda je povolena deduplikace dat, FS pro načítání operačního systému ve výchozím nastavení, alternativní kořen pro připojení, charakteristiky fondu a další.

Systémové atributy úložiště dat

Atributy systému úložiště jsou způsob, jak spravovat možnosti a nastavení úložišť. Mají speciální typy a omezení zápisu. Určují nastavení pro šifrování, kompresi, kontrolní součty, deduplikaci, zálohování, cachování, velikost bloků ukládání dat konkrétních úložišť. Dále udávají velikost svazků, přípojné body FS, dostupnost jednotlivých úložišť pro zápis, příslušnost úložišť k zónám, mandáty, rezervy, kvóty, nastavení automatického vytváření síťových sdílených složek (NFS, SMB), přístupová práva k nim, popř. více. Tyto atributy určují vlastnosti vaultů. Tyto atributy usnadňují správu funkcí souvisejících s FS, které byly dříve prováděny ručně (například nastavení připojení několika dalších souborových systémů, vytváření síťových sdílených položek).

Některé systémové atributy jsou zděděny podřízenými repozitáři; v důsledku toho jsou atributy okamžitě aplikovány také na podřízená úložiště. Atributy řízení komprese, deduplikace, kontrolních součtů dat a podobně se vztahují pouze na nově zapsaná data. Chcete-li je aplikovat na všechna data, je třeba data přepsat (to lze snadno provést odesláním snímků do stejného fondu s opětovným vytvořením úložišť).

Vlastní atributy úložiště dat

Každému datovému úložišti (FS, svazek, snímek atd.) lze přiřadit vlastní atributy. Uživatelské atributy se od systémových liší svými názvy. U vlastních atributů můžete použít libovolný název (od 1 do 2¹⁰ bajtů), ale doporučuje se používat názvy, které obsahují dvojtečku (abyste předešli konfliktům se systémovými atributy), název vaší domény před touto dvojtečkou (abyste se vyhnuli ostatním uživatelům) , název atributu za dvojtečkou. Vlastní atributy dědí podřízené obchody.

Vzhledem k rozvětvenému vývoji nových funkcí v různých operačních systémech se některé z těchto atributů používají jako nové systémové atributy.

Vlastní atributy používají uživatelé a samostatné programy (například program automatického vytváření a zálohování s časovým posuvníkem).

Atributy systému souborů

Pro soubory libovolného typu lze zadat hodnotu několika systémových atributů. [18] Tyto atributy vám umožňují řídit akce se souborem. Atributy rozšířeného souboru mají stejné systémové atributy.

Kromě atributů, které ukládají data vytvoření, posledního přístupu, poslední úpravy, poslední úpravy metadat, existují atributy [19] :

Název atributu Název atributu v příkazu chmod[20] Účel Co dělá OS s tímto atributem
Skrytý hidden Soubory s tímto atributem se nezobrazí v obecném seznamu, pokud je tato možnost povolena a podporována v programu pro výstup souborů. Nic.
řídký sparse Soubor s tímto atributem se doporučuje zpracovávat jako řídký, tj. obsahující bloky nula bajtů, které nejsou uloženy na jednotce, ale jsou implikované. Tento atribut je informativní a nemá nic společného s tím, zda je soubor skutečně řídký. Program pro zpracování souborů pro práci s řídkými soubory ještě potřebuje přijímat data o řídkých blocích souboru z FS. Nic.
Systémový system Soubor s tímto atributem je určen pro OS, nejedná se o uživatelský soubor. Programy obvykle ignorovány. Nic.
Pouze na čtení readonly Soubor s tímto atributem nelze upravit (pouze data, nikoli atributy). Platí pro všechny bez výjimky. Blokuje přístup pro zápis, pokud je atribut nastaven.
Pro archivaci archive Soubor je třeba archivovat. Nic.
Neodstranitelné nounlink U adresářů nelze odstranit ani změnit název adresáře a jména jeho bezprostředních potomků. Pro jiné typy souborů: název souboru nelze smazat ani změnit. Blokuje přístup ke změně názvu a odstranění, pokud je atribut nastaven.
neměnný immutable Soubor s tímto atributem nelze změnit (data, atributy, kromě tohoto samotného atributu a data posledního přístupu). Platí pro všechny bez výjimky. Bloky upravují přístup, pokud je atribut nastaven.
Pouze pro doplnění appendonly Data souboru lze upravit pouze připojením, ale nelze je přepsat. Blokuje přístup pro zápis, pokud je atribut nastaven.
Ne na skládky nodump Nepoužívá se na Solarisu. Přišel z BSD . K úpravě vyžaduje příslušná oprávnění. Nepoužívá se na Solarisu.
V antivirové karanténě av_quarantined Přístup k souboru je omezen, dokud nebude karanténa zrušena. Atribut lze nastavit a odebrat pouze v případě, že máte práva superuživatele (má je antivirus). Blokuje přístup, pokud je atribut nastaven.
Upraveno (po poslední antivirové kontrole) av_modified Označuje, že aktuální verze souboru není zkontrolována antivirem. Nastavit automaticky při vytvoření souboru a při každé změně dat souboru nebo velikosti souboru. Může být nastaven uživatelem s právy ke změně atributů. Resetovat se to dá pouze pokud máte práva superuživatele (má je antivirus). Automaticky nastaví atribut při změně dat, vytvoření souboru.

Rozšířené atributy

Pro každý soubor libovolného typu můžete vytvořit rozšířené atributy. Rozšířený atribut je pojmenované pole bajtů, stejně jako běžný soubor. Rozšířeným atributům, stejně jako běžným souborům, lze přiřadit vlastní oprávnění a systémové atributy. Na rozdíl od běžného souboru nelze pro rozšířené atributy vytvořit rozšířené atributy, pevné odkazy. S rozšířenými atributy souborů lze v omezené míře zacházet jako s normálními soubory. K tomu je pro každý soubor vytvořena nepojmenovaná složka (v době vytvoření prvního rozšířeného atributu), ve které jsou k dispozici běžné soubory odpovídající rozšířeným atributům tohoto souboru. V systému Solaris je tato složka přístupná pomocí nástroje runat[21] .

Delegování pravomocí uživatelům

Správa jednotlivých trezorů může být delegována na uživatele. K tomu má ZFS přidělené pravomoci, které lze delegovat (vytváření úložišť, snímků, jejich mazání, připojování, porovnávání, přeposílání a další). Oprávnění jsou delegována pro vybrané vaulty stejným způsobem jako přiřazování atributů a rozšiřují se na podřízené vaulty.

Uchovávání a zálohování dat

Díky principu „ copy-on-write “ jsou  data v ZFS vždy v konzistentním stavu, soubor nemůže být ztracen v době přepisu [6] .

Při použití svazků s redundancí (svazky RAIDZ) je zajištěna bezpečnost dat pro případ selhání fyzického média [6] [22] , zatímco RAIDZ je efektivní pro relativně dlouhodobé ukládání velkých souborů, zejména při nastavení velikosti bloku odpovídající souborů a při častém přepisování a při umísťování souborů malých velikostí dochází ke zvýšené zátěži procesoru a diskového subsystému [6] .

Omezení

  • Implementace ZFS v Solarisu 10 postrádá transparentní šifrování, které lze nalézt v Solaris 11 a NTFS , i když existuje jeho implementace jako součást projektu OpenSolaris [23] .
  • ZFS nepodporuje přidělování kvót na uživatele nebo skupinu. Místo toho můžete rychle vytvořit FS pro uživatele, z nichž každý bude mít svou vlastní velikost. Jako takové neexistuje žádné praktické řešení kvót pro souborové systémy sdílené různými uživateli (např. projekt vývojářského týmu), kde mohou být data sdílena na uživatele, lze to však implementovat nad zásobníkem ZFS .
  • Rozšíření úložiště je obvykle dosaženo přidáním skupiny disků, jako je vdev (stripe, RAID-Z , RAID-Z2 nebo mirror ). Nová data budou dynamicky využívat všechna dostupná vdevs. Dalším způsobem, jak zvětšit místo na disku, je střídavá výměna fyzických disků za větší, s očekáváním po každé takové operaci, dokud se ZFS nevyléčí . Doba zpracování závisí na množství uložených informací, nikoli na velikosti disku. Pokud se během léčby vytvoří snímek  , proces léčby se restartuje. Je třeba poznamenat, že výměna disků bez ztráty dat je možná pouze v jednom z provozních režimů fondu, který to umožňuje.
  • V současné době není možné snížit počet vdev bez zmenšení velikosti fondu. Vývojový tým ZFS však na tomto problému pracuje. Od vydání Solaris 10 08/11 (aktualizace 10) to stále není implementováno.
  • Rovněž není možné přidat nový disk do pole RAID-Z nebo RAID-Z2 (vdevs). Tato funkce je obtížně implementovatelná. Můžete však vytvořit RAIDZ vdev a přidat jej do zpool .
  • Ve zpoolu nelze kombinovat typy vdev. Pokud máte například odříznutý fond ZFS obsahující disky na SAN , nebudete moci přidávat místní disky jako zrcadlený vdev.
  • Kompletní rekonfigurace datového úložiště vyžaduje uložení dat na externí média (mimo ZFS), zničení poolů a vytvoření nových poolů podle nových pravidel. Ale ve většině případů se můžete zbavit přenosu dat ze starého fondu do nového pomocí ZFS, přičemž zachováte všechna nebo požadovaná data a atributy (bez ukládání mimo ZFS). Přeposílání nepomůže v případě povolení nebo zakázání šifrování, změny omezení názvů souborů, zakázání povinného řízení přístupu, změny velikosti bloku disku a dalších vzácných operací.
  • ZFS není ze své podstaty klastrovaný , distribuovaný nebo paralelní souborový systém a neposkytuje souběžný přístup k datům z různých hostitelů. ZFS je lokální souborový systém.
  • V implementaci ZFS Solaris 11 nemůžete změnit typ vdev v zpool. Pokud máte například fond ZFS obsahující disky (bloková zařízení), nebudete moci zkopírovat obsah disků do běžných souborů a importovat fond z těchto souborů a naopak – přenést fond z běžných souborů do disky.
  • Odstranění velkého množství dat je pomalá blokovací operace (ve verzi fondu 37 a starší), například odstranění fragmentovaného systému souborů o velikosti 100 GiB může trvat déle než minutu a blokuje získání seznamu systémů souborů a některých dalších systémů souborů. akce ve stejném fondu.
  • Neexistuje způsob, jak řídit obnovu fondu po obnovení přístupu k různým kopiím zrcadleného fondu. Systém se sám rozhodne, jak dezinfikovat bazén, i když byly změny provedeny nezávisle na různých kopiích fondu (toto je povoleno).
  • Vážně poškozený bazén nelze opravit a je třeba ho znovu vytvořit. V mnoha případech však lze uživatelská data načíst z poškozeného fondu jejich importem pro čtení.
  • Některé nevyléčitelné poškození fondu v systémových datech nevede k poškození uživatelských dat nebo blokování změn fondu. Při těchto poškozeních bazén zvnějšku funguje normálně po dlouhou dobu a neupozorňuje na nutnost jeho opravy. Ale pokud to nebude opraveno, nakonec ztratí uživatelská data a skončí v neobnovitelném nebo dokonce nečitelném stavu. Schopnost detekovat takové problémy a automaticky (pokud je to možné) je včas opravit není součástí ZFS a vyžaduje samostatnou konfiguraci.

Platformy

ZFS je součástí operačního systému Solaris a je k dispozici pro platformy SPARC i x86 . Vzhledem k tomu, že kód ZFS je open source (licence CDDL), lze porty na jiné operační systémy a platformy vytvářet bez zapojení Oracle.

OpenSolaris

OpenSolaris 2008.05 používá ZFS jako výchozí souborový systém.

Nexenta OS

Nexenta OS  je operační systém s prostředím GNU postaveným na jádře OpenSolaris a jeho runtime prostředí, podpora ZFS byla zahrnuta do verze alpha1 jádra. Nedávno společnost Nexenta Systems představila NexentaStor  , síťový úložný systém s podporou ZFS, který poskytuje funkce NAS / SAN / iSCSI a je založen na OS Nexenta. NexentaStor obsahuje grafické rozhraní, které zjednodušuje proces používání ZFS. 2. prosince 2008 byl vydán NexentaStor 1.1. Aktualizovalo jádro OpenSolaris, zlepšilo integraci s CIFS/AD, přidalo několik pluginů a opravilo některé chyby. Existují dvě edice NexentaStor: komerční Enterprise Edition a bezplatná Community Edition s maximálním limitem úložné kapacity 18 TB. Od srpna 2012 je aktuální verze softwaru 3.1.3.

Linux

Úroveň jádra

Kvůli licenčním omezením CDDL není ZFS součástí jádra, ale je dostupný jako modul jádra, který je nyní dostupný v mnoha distribucích GNU/Linux [6] [24] .

Po dlouhou dobu v Linuxu bylo portování ZFS na úroveň jádra považováno za právně nemožné kvůli nekompatibilitě licencí CDDL , pod jejichž jurisdikci ZFS spadá, a GNU GPL , pod jejíž jurisdikci spadá Linux . V květnu 2010 však Brian Behlendorf představil novou verzi projektu, který pracuje na implementaci nativní podpory souborového systému ZFS pro Linux. Aby obešel licenční omezení, rozhodl se Behlendorf distribuovat celý svůj produkt pod licencí CDDL jako samostatně stahovatelný modul, který je dodáván odděleně od jádra [25] [26] . Od března 2013 (verze 0.6.1) je projekt považován za připravený pro průmyslové využití [24] . Ubuntu 16.04 (64-bit) je první mainstreamová linuxová distribuce, která je připravena na ZFS [27] .

FUSE

Iniciativa Google Summer of Code sponzoruje linuxovou adaptaci ZFS pomocí modulu FUSE , který spouští souborový systém ZFS v uživatelském prostoru [28] . Předpokládá se, že toto řešení je teoreticky plné ztrát výkonu [29] . Ale příklad implementace NTFS ( NTFS-3G ) prostřednictvím FUSE ukazuje dobrý výkon ve srovnání s jinými systémy [30] , což dává důvod předpovídat přijatelný výkon ZFS-FUSE.

Na konci roku 2012 byl ZFS-FUSE [31] představen jako verze 0.7.0, která zahrnovala téměř kompletní podporu ZFS a všech jeho funkcí – byla zavedena podpora 23. verze poolu.

FreeBSD

Pawel Jakub Dawidek upravil ZFS pro FreeBSD jako modul jádra. ZFS je součástí FreeBSD 7.0 (vydáno 27. února 2008) [32] .

Kód ZFSv28 je testován na FreeBSD 9 a portován do stabilní vývojové větve 8. Vydání FreeBSD 8.3, 8.4 a 9.0 podporují verzi 28 fondu ZFS. Vydání FreeBSD 9.2 a novější verze FreeBSD používají nové funkce "feature flags" založené na implementaci Pool verze 5000 [33] .

Je pozoruhodné, že ve FreeBSD od verze 8 ZFS na rozdíl od Linuxu nevyžaduje přítomnost FUSE, a proto s ním nejsou spojeny žádné problémy s výkonem. To potvrzuje i fakt, že ZFS ve FreeBSD je součástí jádra a je v systému okamžitě přítomen, mimo jiné umožňuje zavést operační systém ze svazků ZFS. A modul FUSE není součástí operačního systému a lze jej volitelně nainstalovat z kolekce portů [34] (což je vyžadováno například pro podporu NTFS).

Mac OS X

Apple se pokoušel přenést ZFS na Mac OS X a probíhala aktivní diskuse o ZFS mailing listech a předběžných škrtech pro další verzi Apple Mac OS X [35] . Přestože Mac OS X 10.5 (9A321) podporuje ZFS, nemá možnost používat ZFS na kořenových oddílech, ani nemá možnost formátovat místní disky pod ZFS (to druhé je považováno za chybu [36] ).

V červnu 2009 Apple na své tiskové konferenci WWDC '09 opustil ZFS v prezentované verzi Mac OS X 10.6 Snow Leopard, všechny odkazy na ZFS byly odstraněny z dokumentace a materiálů webu. Důvody nepoužívání ZFS společnost nezveřejňuje [37] .

Zatímco podpora pro ZFS byla vrácena v Mac OS X 10.6 Snow Leopard build 10A432, označeném Golden Master, podpora ZFS byla v konečném vydání Mac OS X 10.6 definitivně opět odstraněna [38] .

V reakci na uzavření oficiální podpory ZFS se objevil bezplatný projekt, který vychází z kódové základny dříve vytvořené Applem, ale liší se způsobem integrace do systému. MacZFS se nespouští na úrovni jádra, ale na uživatelské úrovni, pracující pomocí MacFUSE, byl připraven binární balíček zkompilovaný na základě zdrojových textů publikovaných v repozitáři Git a také konfiguračních pokynů.

redox

Operační systém Redox plánoval použít ZFS jako výchozí souborový systém, ale později přešel na vlastní implementaci podobných principů - TFS [39] [40] , napsaný v hlavním jazyce Redox - Rust .

Poznámky

  1. ↑ zfs/zfs_vnops.c at 12fa7f3436fbd89f4d6b00c2c076405e7a21d62f · zfsonlinux/zfs · GitHub + zfs/zfs_znode.h at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub + zfs/zfs_vfsops.c at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub
  2. ↑ ZFS: poslední slovo v souborových systémech (ZFS: poslední slovo v souborových systémech) . Sun Microsystems (14. září 2004). Získáno 30. dubna 2006. Archivováno z originálu 4. června 2012.
  3. ↑ Jeff Bonwick. ZFS: Poslední slovo v souborových systémech . Blog Jeffa Bonwicka (31. října 2005). Získáno 30. dubna 2006. Archivováno z originálu 13. října 2012.
  4. ↑ Sun slaví úspěšné roční výročí OpenSolaris . Sun Microsystems (20. června 2006). Archivováno z originálu 13. října 2012.
  5. ↑ Jeff Bonwick. Vy říkáte zeta, já říkám zetta (Vy říkáte zeta, já říkám zetta) . Blog Jeffa Bonwicka (4. května 2006). Získáno 8. září 2006. Archivováno z originálu 13. října 2012.
  6. ↑ 1 2 3 4 5 Melnikov, 2020 .
  7. ↑ Spouští se projekt OpenZFS . LWN.net ( 2013-09-17.mdy . 2022 ). Staženo : 2013-10-01.mdy . 2022 . Archivováno z originálu 11. října 2016.
  8. ↑ Oznámení OpenZFS . OpenZFS (2013-09-17.mdy . 2022 ) . Staženo : 2013-09-19.mdy . 2022 . Archivováno z originálu 2. dubna 2018.
  9. ↑ Historie OpenZFS . openzfs. Staženo : 24.09.2013.mdy . 2022 . Archivováno z originálu 24. prosince 2013.
  10. ↑ Nejjednodušší kontrola ukazuje, že v současné implementaci nemůže pool využívat více než 16 EIB. Tuto kontrolu lze snadno provést sami, protože 8 zařízení EIB poskytuje samotný ZFS, minimálně stovky na skutečný gigabajt prostoru při použití komprese.
  11. ↑ Podle vedoucího projektu Bonwicka „Naplnění 128bitových souborových systémů překročí kvantovou kapacitu úložiště dat na Zemi. Nemůžete naplnit a uložit 128bitový objem, aniž byste uvařili oceán.“ Příklad toho, jak velká jsou tato čísla: pokud vytvoříte 1000 souborů každou sekundu, bude trvat asi 9000 let, než ZFS dosáhne limitu souborů. Z výpočtu vyplývá, že potřebný čas je 8925,5129601298833079654997463217 let bez zohlednění změny úhlové rychlosti zápisu na disk a dalších nákladů. V odpovědi na otázku týkající se zaplnění ZFS bez varu oceánů Bonwick píše: „I když bychom všichni chtěli , aby Moorův zákon platil donekonečna, kvantová mechanika klade určité zásadní limity na výpočetní rychlost a informační kapacitu jakéhokoli fyzického zařízení. Konkrétně bylo ukázáno, že 1 kilogram hmoty, omezený 1 litrem prostoru, může provést ne více než 10 51 operací za sekundu na ne více než 10 31 bitech informace [viz obr. Seth Lloyd, „ Nejvyšší fyzické limity pro výpočty Archivováno z originálu 7. srpna 2008. .“ Nature 406, 1047-1054 (2000)]. Plně vyplněný 128bitový svazek bude obsahovat 2128 bloků = 2137 bajtů = 2140 bitů; takže minimální hmotnost potřebná k uložení tohoto počtu bitů by byla ( 2140 bitů) / ( 1031 bitů/kg) = 136 miliard kg.“
  12. ↑ Existují další omezení atributů používaných OS, například velikost atributu FS pro přístupový seznam Solaris NFS je omezena na přibližně 10⁴ bajtů, což odpovídá 2000 až 20 uživatelům v závislosti na délkách přihlášení a hostitelé.
  13. ↑ Specifikace ZFS On-Disk (downlink) . Archivováno z originálu 28. října 2015, Sun Microsystems, Inc.  Viz kapitola 2.4.
  14. ↑ Integrita dat . Zpráva CERN (8. dubna 2007). Datum přístupu: 28. ledna 2008. Archivováno z originálu 13. října 2012.
  15. ↑ Smokin' Mirrors . Blog od Jeffa Bonwicka (2. května 2006). Získáno 23. února 2007. Archivováno z originálu 13. října 2012.
  16. ↑ Přidělení bloků ZFS . Blog Jeffa Bonwicka (4. listopadu 2006). Získáno 23. února 2007. Archivováno z originálu 13. října 2012.
  17. ↑ Stejné bloky - Úžasná repelentní páska . Weblog Flippin' off bits (12. května 2006). Získáno 1. března 2007. Archivováno z originálu 13. října 2012.
  18. ↑ Synopse - manuálové stránky sekce 1: Uživatelské příkazy . Datum přístupu: 13. ledna 2016. Archivováno z originálu 24. října 2016.
  19. ↑ Synopse - manuálové stránky sekce 3: Základní funkce knihovny: fgetattr, fsetattr, getattrat, setattrat - získat a nastavit systémové atributy . Získáno 13. března 2016. Archivováno z originálu 11. října 2016.
  20. ↑ Synopse - manuálové stránky sekce 1: Uživatelské příkazy: chmod - změna režimu oprávnění souboru . Získáno 13. března 2016. Archivováno z originálu dne 25. března 2016.
  21. ↑ Synopse - manuálové stránky sekce 1: Uživatelské příkazy . Datum přístupu: 13. ledna 2016. Archivováno z originálu 2. února 2017.
  22. ↑ Ahrens, 2014 .
  23. ↑ Projekt OpenSolaris: Podpora pro šifrování disku v ZFS. . Projekt OpenSolaris. Získáno 11. července 2008. Archivováno z originálu 13. října 2012.
  24. ↑ 12 Neil McAllister . ZFS připravené na výrobu nabízí úložiště v kosmickém měřítku pro Linux. Spolehlivý souborový systém Über je nyní připraven k širokému nasazení . The Register (30. března 2013). Získáno 30. března 2013. Archivováno z originálu dne 4. dubna 2013.  
  25. ↑ Nativní podpora pro souborový systém ZFS je dostupná pro Linux  : [ arch. 29. května 2010 ] // OpenNET. - 2010. - 27. května.
  26. ↑ Matt Ahrens, Brian Behlendorf. OpenZFS na Linuxu  (anglicky)  (nedostupný odkaz) . LinuxCon 2013 (17. září 2013). Získáno 25. prosince 2013. Archivováno z originálu 13. listopadu 2013.
  27. ↑ Ben Everard . Ubuntu 16.04 Je zpět – a je skvělý. Linux Voice, vydání 27, červen 2016
  28. ↑ Ricardo Correia. Oznámení ZFS na FUSE/Linux (26. května 2006). Získáno 15. července 2006. Archivováno z originálu 13. října 2012.
  29. ↑ Implementace systému souborů na úrovni úloh v uživatelském prostoru může způsobit dodatečné náklady, jako je přepínání kontextu . Ale taková implementace je základem celé teorie mikrojaderných systémů a je spolehlivější než implementace uvnitř jádra.
  30. ↑ Szabolcs Szakacsits. Výkon ovladače pro čtení/zápis NTFS-3G (nedostupný odkaz) (28. listopadu 2007). Získáno 20. ledna 2008. Archivováno z originálu 4. ledna 2007. 
  31. ↑ ZFS pro Linux 0.7.0 . Získáno 7. listopadu 2012. Archivováno z originálu 20. listopadu 2012.
  32. ↑ Dawidek, Pawel ZFS se zavázali k základně FreeBSD (6. dubna 2007). Získáno 6. dubna 2007. Archivováno z originálu dne 13. října 2012.
  33. ↑ Poznámky k vydání FreeBSD 9.2-RELEASE . FreeBSD. Datum přístupu: 30. září 2013. Archivováno z originálu 3. října 2013.
  34. ↑ Kolekce portů FreeBSD . Získáno 21. dubna 2015. Archivováno z originálu 19. dubna 2015.
  35. ↑ Portování ZFS na OSX . zfs-discussions (27. dubna 2006). Získáno 30. dubna 2006. Archivováno z originálu 13. října 2012.
  36. ↑ Mac OS X 10.5 9A326 Seed . Fóra InsanelyMac (14. prosince 2006). Získáno 14. prosince 2006. Archivováno z originálu dne 13. října 2012.
  37. ↑ Linux.Org.Ru . Fóra InsanelyMac (11. června 2009). Získáno 11. června 2009. Archivováno z originálu 13. října 2012.
  38. ↑ Robin Harris - Apple kopne ZFS do zadku . Získáno 2. září 2009. Archivováno z originálu 2. září 2009.
  39. ↑ https://github.com/redox-os/tfs Archivováno 26. října 2018 na Wayback Machine „TFS byl vytvořen z potřeby moderního souborového systému pro Redox OS, jako náhrada za ZFS, který se ukázal být pomalá implementace kvůli jeho monolitickému designu."
  40. ↑ https://www.phoronix.com/scan.php?page=news_item&px=TFS-File-System-Rust-ZFS Archivováno 18. října 2018 na Wayback Machine , https://www.phoronix.com/scan. php ?page=news_item&px=Redox-OS-2016-State Archivováno 18. října 2018 na Wayback Machine

Odkazy

Porty

Recenze a informace

  • ZFS Uncovered  (anglicky)  - přehled souborového systému ZFS.
  • ZFS  (ruština) na Xgu.ru
  • Melnikov G. ZFS  : architektura, vlastnosti a rozdíly od jiných souborových systémů: [ arch. 1. prosince 2020 ] / Georgij Melnikov; Skupina Mail.ru // Habr. - 2020. - 1. prosince.
Zdroj - https://ru.wikipedia.org/w/index.php?title=ZFS&oldid=126380035