ZFS

ZFS

開発者	当初はSun Microsystems、 2010年からはOracle Corporation、2013年からはOpenZFS
バリエーション	Oracle ZFS、OpenZFS
紹介された	2005年11月; 18年前のOpenSolaris ( 2005-11 )
構造
ディレクトリの内容	拡張可能なハッシュテーブル
制限
最大ボリュームサイズ	256兆 ヨビバイト（2128バイト ）[1]
最大ファイルサイズ	16 エクスビバイト(2 64 バイト)
最大ファイル数	ディレクトリあたり: 2 48 ファイルシステムあたり: 無制限[1]
ファイル名の最大長	1023 ASCII文字 ( Unicodeなどのマルチバイト文字規格の場合はそれより少なくなります)
特徴
フォーク	はい（「拡張属性」と呼ばれますが、本格的なストリームです）
属性	POSIX、拡張属性
ファイルシステムの 権限	Unix パーミッション、NFSv4 ACL
透過的な 圧縮	はい
透過的な 暗号化	はい
データ重複排除	はい
コピーオンライト	はい
他の
サポートされている オペレーティングシステム	Sun コードベース: OpenSolaris、illumosディストリビューション、OpenIndiana Oracle ZFS: Solaris OpenZFS: FreeBSD、Mac OS X Server 10.5（読み取り専用に制限）、NetBSD、サードパーティのカーネルモジュール経由のLinux（「ZFS on Linux」）[2]またはZFS- FUSE、OSv

ZFS（旧称Zettabyte File System）は、ボリューム管理機能を備えたファイルシステムです。2001年にSun Microsystems Solarisオペレーティングシステムの一部として始まりました。ZFS を含む Solaris の大部分は、 2005年から約5年間OpenSolarisとしてオープンソースライセンスで公開されていましたが、2009年から2010年にかけてOracle Corporation がSun を買収した際にクローズドソースライセンスになりました。2005年から2010年にかけて、ZFS のオープンソースバージョンはLinux、Mac OS X （ MacZFSとして継続）、FreeBSDに移植されました。2010年、illumosプロジェクトは、ZFS を含む OpenSolaris の最新バージョンをフォークし、オープンソースプロジェクトとして開発を継続しました。2013年、オープンソース ZFS の開発を調整するためにOpenZFSが設立されました。 ^{[3] [4] [5]} OpenZFSはZFSのコアコードを維持管理し、ZFSを使用する組織はZFSをシステムに統合するために必要な特定のコードと検証プロセスを維持します。OpenZFSはUnix系システムで広く使用されています。^{[6] [7] [8]}

保存されたデータの管理には、一般的に2つの側面があります。1つは、 1つまたは複数のブロックストレージデバイス（ハードドライブやSDカードなど）の物理ボリューム管理で、オペレーティングシステム（多くの場合、ボリュームマネージャ、RAIDコントローラ、アレイマネージャ、または適切なデバイスドライバを含む）から見たVDEV（ZFS仮想デバイス）^{[9]としての論理ブロックデバイスへの編成が含まれます。もう1つは、これらの論理ブロックデバイス（}ファイルシステムまたはその他のデータストレージ）に保存されているデータとファイルの管理です。

例: 2 台のハード ドライブと SSD キャッシュ ディスクのRAIDアレイは、デスクトップ コンピュータに組み込まれているチップセットとファームウェアの一部であるIntel の RST システムによって制御されます。Windowsユーザーはこれを、NTFS でフォ​​ーマットされたデータのドライブを含む単一のボリュームとして認識します。また、NTFS は、必要な操作 (キャッシュ ドライブの読み取り/書き込み、ディスク障害時の RAID アレイの再構築など) を必ずしも認識しません。個々のデバイスの管理と単一のデバイスとしてのプレゼンテーションは、その見かけ上のデバイスに保存されているファイルの管理とは異なります。

ZFS は、他のほとんどのストレージ システムとは異なり、これら 2 つの役割を統合し、ボリューム マネージャとファイル システムの両方の役割を果たすという点で特殊です。したがって、物理ディスクとボリューム (そのステータス、状態、ボリュームへの論理配置を含む) だけでなく、そこに保存されているすべてのファイルについても完全な知識を持っています。ZFS は、(適切なハードウェアを使用することを条件に) ディスクに保存されたデータが、物理的なエラー、ハードウェアまたはオペレーティング システムによる処理ミス、または時間の経過と共に発生する可能性のあるビット腐敗イベントやデータ破損によって失われることがないよう設計されています。ストレージ システムを完全に制御することで、ファイル管理に関連するかディスク管理に関連するかに関係なく、すべてのステップが検証、確認、必要に応じて修正、および最適化されます。これは、ストレージ コントローラ カードや個別のボリューム システムおよびファイル システムでは実現できない方法です。

ZFS には、データセットおよびプール レベルのスナップショットとレプリケーションのメカニズムも含まれており、これにはスナップショットのクローン作成が含まれます。これは、 FreeBSDのドキュメントで「スナップショット機能を備えた他のファイル システムにも欠けている」機能を備えた「最も強力な機能」の 1 つとして説明されています。 ^[10]パフォーマンスを低下させることなく大量のスナップショットを作成できるため、リスクのあるシステム操作やソフトウェアの変更の前にスナップショットを使用したり、ユーザー エラーや悪意のあるアクティビティによるデータ損失を軽減するために、実稼働 (「ライブ」) ファイル システム全体を 1 時間に数回完全にスナップショットしたりできます。スナップショットは「ライブ」でロールバックしたり、非常に大規模なファイル システムでも以前のファイル システムの状態を表示したりできるため、正式なバックアップおよび復元プロセスと比較してコストを削減できます。^[10]スナップショットをクローンして、新しい独立したファイル システムを形成することもできます。ZFS には、プール レベルのスナップショット (「チェックポイント」と呼ばれる) を作成する機能もあり、プール全体の構造に影響を与える可能性のある操作や、データセット全体を追加または削除する操作をロールバックできます。

1987年、AT&T社とサンは、当時市場で最も人気のあるUnixの派生製品であるBerkeley Software Distribution、UNIX System V、Xenixを統合するプロジェクトで協力していることを発表しました。これがUnix System V Release 4 (SVR4)となりました。^{[11]このプロジェクトは}Solarisという名前でリリースされ、 SunOS 4の後継となりました（ただし、SunOS 4.1.xマイクロリリースは遡及的に Solaris 1と命名されました）。^[12]

ZFSは、ジェフ・ボンウィック、ビル・ムーア、^[13]、マシュー・アーレンズが率いるサンのチームによって設計および実装されました。2004年9月14日に発表されましたが、 ^[14]開発は2001年に始まりました。 ^[15] ZFSのソースコードは、2005年10月31日にSolaris開発のメイントランクに統合され、 ^{[16] 2005年11月16日に}OpenSolarisのビルド27の一部として開発者向けにリリースされました。2006年6月、サンはZFSがSolaris 10のメインストリーム6/06アップデートに含まれることを発表しました。^[17]

Solarisはもともとプロプライエタリソフトウェアとして開発されましたが、サン・マイクロシステムズはオープンソースソフトウェアの初期の商業的提唱者であり、2005年6月にSolarisコードベースの大部分をCDDLライセンスの下でリリースし、OpenSolaris オープンソースプロジェクトを設立しました。^{[18] Solaris 10 6/06（「U2」）で、サンは}ZFSファイルシステムを追加し、その後5年間にわたってZFSを頻繁に新機能で更新しました。ZFSはこのオープンソースライセンスの下で、 Linux、Mac OS X（MacZFSとして継続）、FreeBSDに移植されました。

この名前はかつて「ゼタバイトファイルシステム」の略称と言われていましたが^[19]、2006年までにこの名前はもはや略語とはみなされなくなりました。^[20] ZFSファイルシステムは最大256兆ゼタバイト（ZB）を保存できます。

2007年9月、NetAppは、ZFSがWrite Anywhere File Layoutに関するNetAppの特許の一部を侵害しているとして、Sunを訴えた。同年10月、Sunは反対の主張をして反訴した。この訴訟は2010年に非公開の和解で終了した。^[21]

ZFS の移植版は 2005 年に登場し始めました。2010 年にSun が Oracle に買収された後、Oracle 版の ZFS はクローズド ソースとなり、2013 年からOpenZFSの調整により、オープンソース バージョンの開発が独自に進められました。

ZFS 固有の機能の例は次のとおりです。

• データの長期保存、データ損失ゼロで無制限に拡張可能なデータストア サイズ、および高度な構成可能性を実現するように設計されています。
• すべてのデータとメタデータの階層的なチェックサムにより、使用時にストレージ システム全体を検証し、正しく保存されていることを確認でき、破損している場合は修復できます。チェックサムは、ブロック自体ではなく、ブロックの親ブロックに保存されます。これは、チェックサム (保持されている場合) がデータと一緒に保存されるため、データが失われたり破損したりすると、チェックサムも失われたり不正確になったりする可能性が高くなる多くのファイル システムとは対照的です。
• ユーザーが指定した数のデータまたはメタデータのコピー、または選択したデータの種類を保存して、重要なファイルや構造のデータ破損からの回復能力を向上させることができます。
• エラーや不整合が発生した場合、状況によっては、ファイル システムとデータへの最近の変更を自動的にロールバックします。
• データの再構築が可能なすべてのエラーについて、データの不整合や書き込みエラーが検出されると、自動的に（通常は）サイレントに自己修復されます。データの再構築には、各ブロックの親ブロックに保存されているエラー検出および修正チェックサム、ディスクに保持されているデータの複数のコピー（チェックサムを含む）、発生するはずだったが発生しなかった書き込み（電源障害後）の SLOG（ZIL）に記録された書き込み意図、RAID/RAID-Z ディスクおよびボリュームからのパリティ データ、ミラーリングされたディスクおよびボリュームからのデータのコピーのすべてを使用できます。
• 標準 RAID レベルと追加の ZFS RAID レイアウト ("RAID-Z") のネイティブ処理。RAID-Z レベルでは、効率化のため、必要なディスクのみにデータをストライプ化します (多くの RAID システムはすべてのデバイスに無差別にストライプ化します)。また、チェックサムにより、不整合または破損したデータの再構築を欠陥のあるブロックに最小限に抑えることができます。
• 階層型ストレージとキャッシュ デバイスのネイティブ処理。これは通常、ボリューム関連のタスクです。ZFS はファイル システムも認識するため、ファイル関連の知識を使用して、個別のデバイスではできない階層型ストレージ処理を通知、統合、最適化できます。
• スナップショットとバックアップ/レプリケーションのネイティブ処理は、ボリュームとファイルの処理を統合することで効率化できます。関連ツールは低レベルで提供されており、使用するには外部のスクリプトとソフトウェアが必要です。
• ネイティブのデータ圧縮と重複排除。ただし、後者は主にRAMで処理され、メモリを大量に消費します。
• RAID アレイの効率的な再構築 - RAID コントローラは多くの場合ディスク全体を再構築する必要がありますが、ZFS はディスクとファイルの知識を組み合わせて、実際に欠落または破損しているデータのみを再構築するように制限できるため、再構築が大幅に高速化されます。
• 他の多くのシステムに影響を与える RAID ハードウェアの変更による影響を受けません。多くのシステムでは、RAID カードなどの自己完結型 RAID ハードウェアが故障したり、データが別の RAID システムに移動されたりすると、ファイル システムには元の RAID ハードウェアにあった情報がなくなってしまいます。この情報は RAID アレイ上のデータを管理するために必要です。ほぼ同一のハードウェアを入手して「踏み石」として使用しない限り、データが完全に失われる可能性があります。ZFS は RAID 自体を管理するため、ZFS プールを他のハードウェアに移行したり、オペレーティング システムを再インストールしたりすることができ、RAID-Z 構造とデータが認識され、ZFS によって再びすぐにアクセスできるようになります。
• キャッシュ内に存在したが最近破棄されたデータを識別する機能。これにより、ZFS は後の使用を考慮してキャッシュの決定を再評価し、非常に高いキャッシュ ヒット レベルを実現できます (ZFS キャッシュ ヒット率は通常 80% 以上です)。
• データ処理で遅延を引き起こす可能性のあるデータには、代替のキャッシュ戦略を使用できます。たとえば、ストレージ システムの速度を低下させる可能性のある同期書き込みは、SLOG (ZIL – ZFS インテント ログと呼ばれることもあります) と呼ばれる高速な別のキャッシュ デバイスに書き込むことで、非同期書き込みに変換できます。
• 高度に調整可能 - 最適な機能を実現するために多くの内部パラメータを構成できます。
• 高可用性クラスターおよびコンピューティングに使用できますが、この用途向けに完全に設計されているわけではありません。

ZFS を他のファイル システムと区別する大きな特徴の 1 つは、データの整合性に重点を置いて設計されていることです。これにより、データの劣化、電力サージ (電圧スパイク)、ディスクファームウェアのバグ、ファントム書き込み (前回の書き込みがディスクに書き込まれなかった)、誤った方向への読み取り/書き込み (ディスクが間違ったブロックにアクセスした)、アレイとサーバー メモリ間またはドライバーからの DMA パリティ エラー (チェックサムがアレイ内のデータを検証するため)、ドライバー エラー (データがカーネル内の間違ったバッファーに格納される)、偶発的な上書き (ライブ ファイル システムへのスワップなど) などによって引き起こされるサイレント データ破損からディスク上のユーザー データを保護します。

1999年の調査では、当時主流で普及していたファイルシステム（UFS、Ext、^[22] XFS、JFS、NTFSなど）もハードウェアRAID（データの整合性に問題がある）も、データ破損の問題に対して十分な保護を提供しないことが示されました。^{[23] [24] [25] [26]}初期の調査では、ZFSが以前の取り組みよりも優れたデータ保護を提供することが示されています。^{[27] [28]} また、UFSよりも高速であり、 ^{[29] [30]} UFSの代替として見ることができます。

ZFS では、ファイルシステムツリー全体でフレッチャーベースのチェックサムまたはSHA-256ハッシュを使用することでデータの整合性が確保されます。 ^[31]各データブロックのチェックサムが計算され、チェックサムの値は実際のブロック自体ではなく、そのブロックへのポインタに保存されます。次に、ブロックポインタのチェックサムが計算され、その値がそのポインタに保存されます。このチェックサム計算は、ファイルシステムのデータ階層をルートノードまでずっと続けられ、ルートノードでもチェックサムが計算され、Merkle ツリーが作成されます。^[31]実行中のデータ破損またはファントム読み取り/書き込み (データの書き込み/読み取りチェックサムは正しいが、実際には間違っている) は、ほとんどのファイルシステムではデータと一緒にチェックサムが保存されるため検出できません。ZFS は、各ブロックのチェックサムを親ブロックポインタに保存し、プール全体が自己検証されるようにします。^[31]

ブロックにアクセスすると、それがデータであるかメタデータであるかに関係なく、そのチェックサムが計算され、保存されている「べき」チェックサム値と比較されます。チェックサムが一致した場合、データはプログラミング スタックを介して、そのデータを要求したプロセスに渡されます。値が一致しない場合は、ストレージ プールがデータ冗長性(内部ミラーリングなど) を提供している場合、データのコピーが破損しておらず、チェックサムが一致していると仮定すると、ZFS はデータを修復できます。^{[32]オプションで、} copys=2 (またはcopies=3 )を指定して、プール内の冗長性をさらに高めることもできます。これは、データがディスクに 2 回 (または 3 回) 保存されることを意味し、ディスクのストレージ容量が実質的に半分 (または、copys=3の場合は3 分の 1) になります。^[33]さらに、ZFS がプールを管理するために使用する一部の種類のデータは、安全のため、デフォルトの copies=1 設定でもデフォルトで複数回保存されます。

破損したデータの他のコピーが存在する場合、またはチェックサムとパリティデータから再構築できる場合、ZFS はデータのコピーを使用して (または RAID 回復メカニズムを使用して再作成して)、チェックサムを再計算します。理想的には、元の予想値が再現されます。データがこの整合性チェックに合格すると、システムはすべての障害のあるコピーを既知の正常なデータで更新し、冗長性が復元されます。

破損したデータのコピーがない場合、ZFSはプールを障害状態にし、^[34]将来の使用を妨げ、プールの内容を回復するための文書化された方法を提供しません。

ZFSはエラー訂正RAMを搭載したエンタープライズ品質のハードウェア上で動作することが想定されているため、ARCにキャッシュされたデータなど、メモリ内に保持されたデータの一貫性はデフォルトではチェックされません。ただし、メモリ内のデータをチェックする機能が存在し、「デバッグフラグ」を使用して有効にすることができます。^[35]

ZFS がデータの整合性を保証するには、通常は複数のディスクに分散されたデータの複数のコピーが必要です。これは通常、RAIDコントローラまたはいわゆる「ソフト」 RAID (ファイル システムに組み込まれている) のいずれかを使用して実現されます。

ZFS はハードウェアRAIDデバイスで動作できますが、すべてのストレージ デバイスに raw アクセスできる場合、通常はより効率的に動作し、データ保護も強化されます。ZFS は、データが安全に書き込まれたと確認された瞬間を判断するためにディスクの正直なビューに依存しており、キャッシュ、キャッシュ フラッシュ、およびディスク処理の使用を最適化するように設計された多数のアルゴリズムを備えています。

ハードウェア、ファームウェア、その他の「ソフト」RAID、または ZFS からディスクへのI/Oパスを変更するその他のコントローラを使用してシステムに接続されたディスクは、ZFS のパフォーマンスとデータの整合性に影響します。サードパーティのデバイスがキャッシュを実行したり、ZFS が依存する低レベルのビューなしでドライブを単一のシステムとして ZFS に提示したりする場合、システムのパフォーマンスが低下し、ZFS が障害を防止しにくくなったり、障害からの回復が遅くなったり、書き込みエラーによってデータが失われたりする可能性が高くなります。たとえば、ハードウェア RAID カードが使用されている場合、ZFS はディスクの状態を判断できない、RAID アレイが劣化しているか再構築中であるかを判断できない、すべてのデータ破損を検出できない、ディスク間でデータを最適に配置できない、選択的な修復を実行できない、修復と使用中の継続とのバランスを制御できない、または ZFS が通常実行できる修復を実行できない可能性があります。ハードウェア RAID カードは ZFS のアルゴリズムに干渉します。また、RAID コントローラは通常、コントローラ依存のデータをドライブに追加するため、ソフトウェア RAID がユーザー データにアクセスできなくなります。ハードウェア RAID コントローラに障害が発生した場合、互換性のある別のコントローラを使用してデータを読み取ることができる可能性がありますが、常に可能であるとは限らず、交換品が入手できない場合もあります。代替ハードウェア RAID コントローラは、アレイの管理と復元に必要な元の製造元のカスタム データを認識できない場合があります。

RAID カードや類似のハードウェアを使用してリソースと処理をオフロードし、パフォーマンスと信頼性を向上できる他のほとんどのシステムとは異なり、ZFS では、これらの方法を使用すると通常、システムのパフォーマンスと信頼性が低下するため、これらの方法を使用しないことを強くお勧めします。

ディスクを RAID または他のコントローラを介して接続する必要がある場合は、プレーンHBA (ホスト アダプタ)や単純なファンアウトカードを使用してコントローラで行われる処理量を最小限に抑えるか、カードをJBODモード (つまり RAID とキャッシュ機能をオフにする) で構成して、ZFS からディスクへの I/O パスの変更を最小限に抑えてデバイスを接続できるようにすることをお勧めします。JBOD モードの RAID カードは、キャッシュがある場合に干渉する可能性があります。また、設計によっては、時間内に応答しないドライブを切り離す可能性があります (多くのエネルギー効率の高い消費者向けハード ドライブで見られるように)。そのため、ドライブのドロップアウトを防ぐために、時間制限エラー回復(TLER)/CCTL/ERC 対応のドライブが必要になる場合があります。そのため、RAID 機能を無効にしてもすべてのカードが適しているわけではありません。^[36]

ZFS はハードウェア RAID の代わりに「ソフト」 RAID を採用し、RAID-Z ( RAID 5などのパリティベース) とディスク ミラーリング( RAID 1に類似) を提供します。このスキームは非常に柔軟です。

RAID-ZはRAID-5のようなデータ/パリティ分散方式ですが、動的なストライプ幅を使用します。ブロックサイズに関係なく、すべてのブロックが独自のRAIDストライプであるため、RAID-Zのすべての書き込みはフルストライプ書き込みになります。これをZFSのコピーオンライトトランザクションセマンティクスと組み合わせると、書き込みホールエラーがなくなります。RAID-Zは通常の読み取り-変更-書き込みシーケンスを実行する必要がないため、従来のRAID 5よりも高速です。^[37]

すべてのストライプのサイズが異なるため、RAID-Z の再構築では、実際の RAID-Z ジオメトリを決定するためにファイルシステムのメタデータをトラバースする必要があります。ファイルシステムと RAID アレイが別々の製品である場合、これは不可能ですが、データの論理的および物理的な構造の統合ビューがある場合は実現可能になります。メタデータをトラバースすると、ZFS は 256 ビットのチェックサムに対して各ブロックを検証できますが、従来の RAID 製品では通常これができません。^[37]

RAID-Z はディスク全体の障害を処理するだけでなく、サイレント データ破損を検出して修正し、「自己修復データ」を提供することもできます。RAID-Z ブロックを読み取る際、ZFS はそれをチェックサムと比較し、データ ディスクが正しい答えを返さなかった場合、ZFS はパリティを読み取り、どのディスクが不良データを返したかを判断します。次に、破損したデータを修復し、要求者に正常なデータを返します。^[37]

RAID-Z とミラーリングには特別なハードウェアは必要ありません。信頼性のために NVRAM は必要ありませんし、パフォーマンスやデータ保護のために書き込みバッファリングも必要ありません。RAID-Z を使用すると、ZFS は安価な市販ディスクを使用して高速で信頼性の高いストレージを提供します。^{[プロモーション? ] [37]}

RAID-Zには5つのモードがあります。ストライピング（RAID 0に似ており、冗長性はありません）、RAID-Z1（RAID 5に似ており、1つのディスクの障害を許容します）、RAID-Z2（RAID 6に似ており、2つのディスクの障害を許容します）、RAID-Z3（RAID 7 ^[a]構成、3つのディスクの障害を許容します）、ミラーリング（RAID 1に似ており、1つを除くすべてのディスクの障害を許容します）です。^[39]

RAID-Z3 の必要性は、2000 年代初頭に数テラバイトの容量のドライブが一般的になったことで生まれました。この容量の増加は、スループット速度の増加に伴わないため、ドライブの故障によるアレイの再構築が完了するまでに「数週間または数か月かかる」可能性がありました。^[38]この間、アレイ内の古いディスクは追加の作業負荷によってストレスを受け、データの破損やドライブの故障につながる可能性があります。パリティを増やすことで、RAID-Z3 は冗長性を高めるだけでデータ損失の可能性を減らします。^[40]

ZFSにはfsck（ファイルシステム用の標準的なUnixおよびLinuxのデータチェックおよび修復ツール）に相当するツールはありません。 ^[41]代わりに、ZFSにはすべてのデータを定期的に検査し、サイレント破損やその他の問題を修復する組み込みのスクラブ機能があります。いくつかの違いは次のとおりです。

• fsck はオフラインのファイルシステムで実行する必要があります。つまり、ファイルシステムはアンマウントする必要があり、修復中は使用できません。一方、scrub はマウントされたライブ ファイルシステムで使用するように設計されているため、ZFS ファイルシステムをオフラインにする必要はありません。
• fsck は通常、メタデータ (ジャーナル ログなど) のみをチェックし、データ自体はチェックしません。つまり、fsck 後でも、データは保存されている元のデータと一致しない可能性があります。
• チェックサムがデータと一緒に保存されている場合 (多くのファイル システムでよくあるケース)、fsck は必ずしもデータを検証して修復できるとは限りません。これは、チェックサムも破損しているか読み取り不可能な場合があるためです。ZFS は常にチェックサムを検証するデータとは別に保存するため、信頼性が向上し、scrub によるボリュームの修復能力が向上します。また、ZFS はデータの複数のコピーを保存します。特にメタデータは 4 つまたは 6 つのコピー (ディスクごとに複数のコピー、ボリュームごとに複数のディスク ミラー) を持つことができるため、fsck と比較して scrub によるボリュームの広範囲な損傷の検出と修復能力が大幅に向上します。
• scrub は、メタデータとデータを含むすべてをチェックします。fsck と scrub の時間を比較することで、その効果を確認できます。大規模な RAID での fsck は数分で完了することがありますが、これはメタデータのみがチェックされたことを意味します。大規模な RAID 上のすべてのメタデータとデータを走査するには、何時間もかかります。これはまさに scrub が行うことです。
• fsckは利用可能なファイルシステムデータを使用してエラーを検出し、修復しようとしますが、scrubは冗長性を利用して問題から回復します。fsckは部分的なデータ損失でファイルシステムを修復しますが、scrubは冗長性がない場合にはファイルシステムを障害状態にします。^[34]

Sun/Oracleの公式推奨事項は、エンタープライズレベルのディスクを月に1回、安価な市販のディスクを週に1回スクラブすることです。^{[42] [43]}

ZFSは128ビットファイルシステムなので^{[44] [16] 、} Btrfsなどの64ビットシステムよりも1.84×10 ¹⁹倍多くのデータを処理できます。ZFSの最大制限は非常に大きく設計されているため、実際には遭遇することはありません。たとえば、単一のzpoolに2128^{ビットのデータを完全に格納するには、3×10 24}  TBのハードディスクドライブが必要です。 ^[45]

ZFS の理論上の制限は次のとおりです。

• 16エクスビバイト(2 ⁶⁴バイト): 単一ファイルの最大サイズ
• 2 ⁴⁸ : 個々のディレクトリ内のエントリ数^[46]
• 16 エクサバイト: 属性の最大サイズ
• 2 ⁵⁶ : ファイルの属性の数 (実際にはディレクトリ内のファイル数は2 ^{48に制限されます)}
• 256 京ゼビバイト(2 ¹²⁸バイト): zpool の最大サイズ
• 2 ⁶⁴ : 任意の zpool 内のデバイスの数
• 2 ⁶⁴ : zpool 内のファイルシステムの数
• 2 ⁶⁴ : システム内の zpool の数

^{Oracle Solarisでは、ZFS [47]}の暗号化機能がI/Oパイプラインに組み込まれています。書き込み中、ブロックは圧縮、暗号化、チェックサム計算、重複排除の順に実行されます。暗号化ポリシーは、データセット（ファイルシステムまたはZVOL）の作成時にデータセットレベルで設定されます。ユーザー/管理者が提供するラッピングキーは、ファイルシステムをオフラインにすることなくいつでも変更できます。デフォルトの動作では、ラッピングキーはすべての子データセットに継承されます。データ暗号化キーは、データセットの作成時にランダムに生成されます。子孫データセット（スナップショットとクローン）のみがデータ暗号化キーを共有します。^[48]クローンまたはいつでも新しいデータ暗号化キーに切り替えるコマンドが提供されています。これは、既存のデータを再暗号化するのではなく、暗号化されたマスターキーメカニズムを利用します。

2019年現在、^{[アップデート]}暗号化機能はDebianおよびUbuntu Linuxディストリビューションで利用可能なOpenZFS 0.8.0にも完全に統合されています。^[49]

ZFSネイティブ暗号化を使用した際に障害が発生したというエンドユーザーからの報告がいくつかあるが、正確な原因は解明されていない。^{[50] [51]}

ZFS は、プールのパフォーマンスが最大化されるように、プール内のすべての vdev (および各 vdev 内のすべてのデバイス) にデータ ストレージを自動的に割り当てます。また、ZFS は、プールに新しいディスクが追加されたときに、そのディスクを考慮して書き込み戦略を更新します。

一般的なルールとして、ZFS は各 vdev の空き領域に基づいて書き込みを vdev に割り当てます。これにより、新しいデータを保存するときに、すでにデータが少ない vdev により多くの書き込みが与えられます。これにより、プールの使用が増えるにつれて、一部の vdev がいっぱいになり、限られた数のデバイスで書き込みが発生するという状況が発生しないようにすることができます。また、データの読み取り (ほとんどの使用では読み取りは書き込みよりもはるかに頻繁です) 時に、データのさまざまな部分を可能な限り多くのディスクから同時に読み取ることができるため、読み取りパフォーマンスが大幅に向上します。したがって、一般的なルールとして、プールと vdev を管理し、新しいストレージを追加して、プール内の一部の vdev がほぼいっぱいで他の vdev がほぼ空になるという状況が発生しないようにする必要があります。このような状況が発生すると、プールの効率が低下します。

ZFSの空き領域は、使用頻度に応じて断片化される傾向があります。ZFSには空き領域をデフラグするメカニズムがありません。空き領域の断片化が進み、ディスク領域の過剰使用と相まってパフォーマンスが低下するというエンドユーザーからの報告があります。^{[52] [53]}

プールには、障害が発生したディスクを補うためのホット スペアを含めることができます。ミラーリング時に、ブロック デバイスを物理シャーシごとにグループ化できるため、シャーシ全体に障害が発生した場合でもファイル システムを続行できます。

ストレージプールの構成は、類似のデバイスに限定されず、アドホックな異機種デバイスの集合で構成することができ、ZFS はそれらをシームレスにプールし、必要に応じてデータセット (ファイルシステムインスタンスまたは ZVOL) にスペースを割り当てます。任意のストレージデバイスタイプを既存のプールに追加して、サイズを拡張できます。^[54]

すべての vdev のストレージ容量は、zpool 内のすべてのファイル システム インスタンスで使用できます。クォータを設定して、ファイル システム インスタンスが占有できるスペースの量を制限することができます。また、予約を設定して、ファイル システム インスタンスでスペースが使用可能であることを保証することもできます。

ZFS は、読み取りおよび書き込み操作を高速化するために、異なる層のディスク キャッシュを使用します。理想的には、すべてのデータを RAM に保存する必要がありますが、通常はコストがかかりすぎます。そのため、パフォーマンスとコストを最適化するために、データは自動的に階層的にキャッシュされます。 ^[55]これらは、「ハイブリッド ストレージ プール」と呼ばれることがよくあります。^[56]頻繁にアクセスされるデータは RAM に保存され、あまり頻繁にアクセスされないデータは、ソリッド ステート ドライブ(SSD) などの低速メディアに保存できます。あまりアクセスされないデータはキャッシュされず、低速のハード ドライブに残されます。古いデータが突然頻繁に読み取られる場合、ZFS はそれを SSD または RAM に自動的に移動します。

ZFS キャッシュ メカニズムには、読み取り用と書き込み用にそれぞれ 1 つずつ含まれており、それぞれの場合で、コンピュータ メモリ (RAM) に 1 つ、高速ストレージ (通常はソリッド ステート ドライブ(SSD)) に 1 つの 2 つのレベルのキャッシュが存在するため、合計 4 つのキャッシュになります。

ZFS 内には、他の多くのキャッシュ、キャッシュ分割、およびキューも存在します。たとえば、各 VDEV には独自のデータ キャッシュがあり、ARC キャッシュは、ユーザーが保存したデータとZFS が使用するメタデータに分割され、それらのバランスが制御されます。

OpenZFS 0.8以降では、ファイルシステムのメタデータ、オプションでデータ重複排除テーブル（DDT）、および小さなファイルシステムブロックを優先的に格納するように特別なVDEVクラスを構成できます。^[58]これにより、たとえば、通常のファイルデータを回転ディスクに格納しながら、メタデータを格納するための特別なVDEVを高速ソリッドステートストレージに作成できます。これにより、ファイルシステム全体をソリッドステートストレージに格納するコストをかけずに、ファイルシステムのトラバーサル、スクラブ、および再シルバーなどのメタデータを集中的に使用する操作を高速化できます。

ZFS はコピーオンライト トランザクション オブジェクトモデルを使用します。ファイルシステム内のすべてのブロックポインタには、対象ブロックの 256 ビットチェックサムまたは 256 ビットハッシュ(現在はFletcher-2、Fletcher-4、またはSHA-256から選択) ^[59]が含まれており、ブロックの読み取り時に検証されます。アクティブデータを含むブロックは、その場で上書きされることはありません。代わりに、新しいブロックが割り当てられ、変更されたデータが書き込まれ、次にそれを参照するメタデータブロックが同様に読み取り、再割り当てされ、書き込まれます。このプロセスのオーバーヘッドを削減するために、複数の更新はトランザクショングループにグループ化され、同期書き込みセマンティクスが必要な場合は ZIL (インテントログ) 書き込みキャッシュが使用されます。ブロックはツリー状に配置され、チェックサムも同様にツリー状に配置されます ( Merkle 署名スキームを参照)。

コピーオンライトの利点は、ZFS が新しいデータを書き込むときに、古いデータを含むブロックを保持できるため、ファイル システムのスナップショットバージョンを維持できることです。ZFS スナップショットは一貫性があり (ある時点で存在していたデータ全体を反映します)、スナップショットを構成するすべてのデータがすでに保存されているため、非常に迅速に作成できます。また、ストレージ プール全体のスナップショットが 1 時間に数回作成されることもあります。変更されていないデータはファイル システムとそのスナップショット間で共有されるため、スペース効率も優れています。スナップショットは本質的に読み取り専用であるため、作成後に変更されることはありません。ただし、バックアップの唯一の手段としては使用しないでください。スナップショット全体を復元することも、スナップショット内のファイルやディレクトリを復元することもできます。

書き込み可能なスナップショット (「クローン」) も作成でき、ブロックのセットを共有する 2 つの独立したファイル システムが作成されます。いずれかのクローン ファイル システムに変更が加えられると、それらの変更を反映する新しいデータ ブロックが作成されますが、クローンがいくつ存在しても、変更されていないブロックは引き続き共有されます。これは、Copy-on-write の原則の実装です。

ZFS ファイル システムは、send コマンドによってファイル システムの状態のストリーム表現が作成されるため、ネットワーク経由でリモート ホスト上の他のプールに移動することもできます。このストリームは、特定のスナップショットでのファイル システムの完全な内容を記述することも、スナップショット間の差分にすることもできます。差分ストリームの計算は非常に効率的で、そのサイズはスナップショット間で変更されたブロックの数によって異なります。これにより、オフサイト バックアップやプールの高可用性ミラーを同期するなど、効率的な戦略が提供されます。

スループットを最大化するためにすべてのデバイス間で動的ストライピングを行うということは、zpoolにデバイスが追加されると、ストライプ幅が自動的に拡張されてそれらのデバイスが含まれるようになることを意味します。したがって、プール内のすべてのディスクが使用され、書き込み負荷がそれらの間で分散されます。^[60]

ZFS は可変サイズのブロックを使用し、デフォルト サイズは 128 KB です。特定のワークロードは大きなブロックではパフォーマンスが十分でないため、管理者は使用可能な機能を使用して、使用される最大ブロック サイズを調整できます。データ圧縮が有効になっている場合は、可変ブロック サイズが使用されます。ブロックを圧縮してより小さなブロック サイズに収まる場合は、ディスク上でより小さなサイズが使用され、ストレージの使用量が減り、IO スループットが向上します (ただし、圧縮および解凍操作で CPU 使用率が増加するという代償があります)。^[61]

ZFS では、ストレージ プール内のファイル システム操作は、従来のファイル システム内のボリューム操作よりも簡単です。ZFS ファイル システムの作成または拡張に必要な時間と労力は、他のシステムでのボリューム操作よりも、新しいディレクトリの作成にかかる時間と労力に近いです。^{[引用が必要]}

プールとそれに関連付けられた ZFS ファイル システムは、異なるバイト オーダーを実装するシステムを含む、異なるプラットフォーム アーキテクチャ間で移動できます。ZFS ブロック ポインター形式は、ファイル システムのメタデータをエンディアンに適応した方法で保存します。個々のメタデータ ブロックは、ブロックを書き込むシステムのネイティブ バイト オーダーで書き込まれます。読み取り時に、保存されたエンディアンがシステムのエンディアンと一致しない場合、メタデータはメモリ内でバイト スワップされます。

これは保存されたデータには影響しません。POSIX システムでは通常、ファイルはアプリケーションに対して単純なバイト配列として表示されるため、データの作成と読み取りを行うアプリケーションは、基盤となるシステムのエンディアンとは無関係に、データの作成と読み取りを行う責任を負います。

データ重複排除機能は2009年10月末にZFSソースリポジトリに追加され、^[62]関連するOpenSolaris ZFS開発パッケージは2009年12月3日（ビルド128）から利用可能になりました。

重複排除を効果的に使用するには、大容量の RAM が必要になる場合があります。推奨される RAM 容量は、ストレージ 1 TB あたり 1～5 GB です。^{[63] [64] [65]}重複排除に必要なメモリの正確な評価は、プール内の一意のブロック数と、各レコードを格納するために必要なディスク上および RAM (「コア」) のバイト数を参照することで行います。これらの数値は、やなどの組み込みコマンドによって報告されますzpool。zdb物理メモリが不足していたり​​、ZFS キャッシュが不足していると、重複排除の使用時に仮想メモリのスラッシングが発生し、パフォーマンスが急激に低下したり、メモリが完全に枯渇したりする可能性があります。^[要出典]重複排除は書き込み時に行われるため、CPU への負荷も大きく、これによってもシステムの速度が大幅に低下する可能性があります。

他のストレージベンダーは、非常に高いデータ圧縮率を実現するために、ZFSの改良版を使用しています。2012年の例としては、GreenBytes ^[66]とTegile ^[67]があります。 2014年5月、OracleはZFSの重複排除およびレプリケーション技術のためにGreenBytesを買収しました。^[68]

前述のように、重複排除は、システムとデータがこのスペース節約技術に適している特定の状況を除いて、リソース要件 (特に RAM) が大きく、パフォーマンス (特に書き込み時) に影響を与えるため、通常は推奨されません。

• 期限スケジュールによる明示的な I/O 優先順位。^{[引用が必要]}
• 全体的に最適な I/O ソートと集約を主張した。^{[引用が必要]}
• 長さとストライドを自動的に検出する複数の独立したプリフェッチ ストリーム。^{[引用が必要]}
• 並列かつ一定時間のディレクトリ操作。^[要出典]
• エンドツーエンドのチェックサム、一種の「データ整合性フィールド」を使用して、データ破損の検出（およびプールに冗長性がある場合は回復）を可能にします。速度（fletcher）、標準化とセキュリティ（ SHA256）、ソルトハッシュ（Skein ）に最適化された3つのハッシュを選択できます。^[69]
• 透過的なファイルシステム圧縮。LZJB 、gzip、^[70] LZ4、Zstdをサポートします。
• インテリジェントなスクラビングと再シルバー化（再同期）^[71]
• プール内のディスク間での負荷とスペースの使用の共有。^[72]
• ディットブロック: ファイルシステムごとに設定可能なデータ複製。ユーザーデータに対しては書き込みごとに0、1、または2つの追加コピーが要求され、メタデータに対しては同じ基本コピー数に1または2が加算されます（メタデータの重要度に応じて）。^[73]プールに複数のデバイスがある場合、ZFSは異なるデバイスに複製を試みます。ディットブロックは主に破損したセクターに対する追加保護であり、ディスク全体の障害に対する保護ではありません。^[74]
• ZFS 設計 (コピーオンライト + スーパーブロック) は、書き込みキャッシュが有効になっているディスクを使用する場合、書き込みバリアを尊重すれば安全です。^{[引用が必要]}この機能により、他のファイルシステムと比較して安全性とパフォーマンスが向上します。^{[誰が言っているのですか? ]}
• Solaris では、ディスク全体が ZFS プールに追加されると、ZFS は自動的に書き込みキャッシュを有効にします。ZFS がディスクの個別のスライスのみを管理する場合は、他のスライスが UFS などの書き込みキャッシュセーフでないファイルシステムによって管理されているかどうかがわからないため、この処理は実行されません。 [^{引用が必要] FreeBSD 実装は、} GEOMフレームワークのおかげでパーティションのディスク フラッシュを処理できるため、この制限の影響を受けません。^{[引用が必要]}
• ユーザーごと、グループごと、プロジェクトごと、データセットごとのクォータ制限。^[75]
• Solaris 11 Express以降のファイルシステム暗号化^[76]およびOpenZFS（ZoL）0.8。^[58]（他のシステムでは、ZFSは暗号化されたディスクを利用して同様の効果を得ることができます。FreeBSD上のGELIをこのように使用して、完全に暗号化されたZFSストレージを作成できます）。
• プールは読み取り専用モードでインポートできます。
• zpool のインポート時にトランザクション全体をロールバックすることでデータを回復することが可能です。^{[引用が必要]}
• スナップショットは手動でも自動でも作成できます。スナップショットに含まれる保存データの古いバージョンは、完全な読み取り専用ファイルシステムとして公開できます。また、CIFS ( SMB、Samba 、ファイル共有とも呼ばれる) で使用すると、ファイルやフォルダの履歴バージョンとして公開することもできます。これは、 Windowsでは「以前のバージョン」、「VSS シャドウコピー」、または「ファイル履歴」、Apple デバイスではAFPおよび「Apple Time Machine」として知られています。 ^[77]
• ディスクは「スペア」としてマークできます。データ プールは、必要に応じてスペア ディスクをアクティブ化し、疑わしいディスクにあったデータをそのディスクに再同期化することで、ディスク障害を自動的かつ透過的に処理するように設定できます。

• Solaris 10 Update 11およびSolaris 11.2の時点では、ホットスペア、キャッシュ、ログデバイスを除くプール内の最上位vdevの数を減らすことも、プール容量を減らすこともできませんでした。^[78]この機能は2007年に開発中と言われていました。 ^[79] vdevの削減を可能にする機能強化は、OpenZFSで開発中です。^{[80]冗長性のない最上位vdevを削除することによるオンライン縮小は、2018年8月にリリースされたSolaris 11.4 [81]}および2019年5月にリリースされたOpenZFS (ZoL) 0.8以降でサポートされています。 ^[58]
• 2008年時点では、^[update]RAID Z、RAID Z2、またはRAID Z3 vdevに列としてディスクを追加することはできませんでした。ただし、代わりに新しいRAID Z vdevを作成し、zpoolに追加することはできます。^[82]
• RAID 51（RAID 5グループのミラー）などの従来のネストされたRAID構成は、サードパーティのツールがなければZFSでは構成できません。^[83]デフォルトのZFS管理コマンドを使用すると、vdevはrawディスクまたはファイルでのみ構成でき、他のvdevで構成することはできません。^[84]ただし、ZFSプールはvdev全体にストライプ（RAID 0）を効果的に作成するため、RAID 50またはRAID 60と同等のものが一般的です。
• トップレベルの vdev 内のデバイス数を再設定するには、データをオフラインでコピーし、プールを破棄し、新しいトップレベルの vdev 構成でプールを再作成する必要があります。ただし、既存のミラーに冗長性を追加する場合は除きます。これはいつでも実行できます。また、すべてのトップレベルの vdev が十分な冗長性を持つミラーである場合は、zpool split ^[85]コマンドを使用して、プール内の各トップレベルの vdev から vdev を削除し、同一データを持つ 2 番目のプールを作成することもできます。

ZFS にはfsckなどのツールは付属していません。これは、ファイル システム自体が自己修復するように設計されているためです。ストレージ プールがストレージの設計とデータの冗長性に十分配慮して構築されている限り、fsckなどの基本的なツールは必要ありませんでした。ただし、ハードウェアの不良、不適切な設計や冗長性、または不幸な事故によりプールが危険にさらされ、ZFS がプールをマウントできなくなった場合、従来、エンド ユーザーがひどく破損したプールから保存されたデータを部分的に回復できるようにする、より高度なツールは他にありませんでした。

最新の ZFS では、時間の経過とともにこの状況が大幅に改善され、現在も改善が続いています。

• キャッシュ デバイスの削除や突然の障害によってプールが失われることはなくなりました。(最悪の場合、ZIL が失われると最新のトランザクションが失われる可能性がありますが、ZIL には通常、数秒分以上の最新のトランザクションは保存されません。L2ARC キャッシュが失われてもデータには影響しません。)
• プールがマウントできない場合、ZFS の最新バージョンは、プールを回復できる最新の一貫性のあるポイントを特定しようとしますが、その代償として、コンテンツへの最新の変更の一部が失われます。コピー オン ライトとは、最上位のレコードやメタデータなどのデータの古いバージョンが、置き換えられてもまだ存在する可能性があることを意味します。その場合、プールはそれらに基づいて一貫性のある状態に戻すことができます。データが古ければ古いほど、少なくとも一部のブロックが上書きされ、一部のデータが回復不能になる可能性が高くなるため、プールを巻き戻す能力には、ある時点で制限があります。
• 非公式には、ZFS がプールをマウントできない理由を調査し、プールを強制的にマウントするために必要な手動の変更についてユーザーまたは開発者をガイドするツールが存在します。これには、zdb (ZFS デバッグ) を使用してプール内の有効なインポート可能なポイントを見つける、dtraceまたは同様のものを使用してマウント失敗の原因となる問題を特定する、またはマウント プロセスを中止するヘルス チェックを手動でバイパスして、破損したプールのマウントを許可することが含まれます。
• 2018年3月現在^[update]、OpenZFSでは大幅に強化されたさまざまなメソッドが徐々に展開されています。これには以下が含まれます。^[86]

• コードのリファクタリング、マウント失敗に関するより詳細な診断およびデバッグ情報により、破損したプールの問題の診断と修正が簡素化されます。
• 保存されたプール構成を信頼または不信頼にする機能。これは特に強力で、トップレベルの vdev が欠落または不良の場合、トップレベルのデータが疑わしい場合でもプールをマウントでき、また、プール構成の変更が問題に関係している場合は、その変更を超えて巻き戻すことができます。破損したプールがマウントされると、安全のために読み取り可能なファイルをコピーできます。また、プール内の他の場所に保存されているコピーを使用して、欠落した vdev のデータを再構築できる場合があります。
• あるプールに必要なディスクが誤って削除され、別のプールに追加されたために、最初のプールに関連するメタデータが失われ、読み取り不能になる状況を修正する機能。

Oracle Corporation は、2010 年に Sun を買収した後、ZFS と OpenSolaris の両方の公開開発を中止しました。一部の開発者は、OpenSolaris の最後の公開リリースを Illumos プロジェクトとしてフォークしました。ZFS には大きな利点があるため、さまざまな機能とコマンドを備えたさまざまなプラットフォームに移植されています。開発作業を調整し、断片化を回避するために、 2013 年にOpenZFSが設立されました。

ZFSの主要設計者の一人であるマット・アーレンズ氏によると、2019年現在、オリジナルのOpenSolaris ZFSコードの50%以上がコミュニティの貢献によってOpenZFSに置き換えられており、「Oracle ZFS」と「OpenZFS」は政治的にも技術的にも互換性がないとのことです。^[87]

• 2008年: SunはZFSベースの7000シリーズストレージアプライアンスを出荷した。^[88]
• 2013年：オラクルはZFSベースのファイラーであるZS3シリーズを出荷し、そのうちの1つでSPC-2ベンチマークで1位を獲得しました。^[89]
• 2013年：iXsystemsはSOHO向けにFreeNAS（現在はTrueNAS COREと改名）と呼ばれるZFSベースのNASデバイスと、企業向けにTrueNASを出荷した。 ^{[90] [91]}
• 2014年：Netgearは、企業向けに設計されたZFSベースのNASデバイス「ReadyDATA」を発売した。 ^[92]
• 2015年: rsync.netは、顧客が独自のzpoolをプロビジョニングし、zfs sendとzfs receiveを使用してデータをインポートおよびエクスポートできるクラウドストレージプラットフォームを発表しました。 ^{[93] [94]}
• 2020年：iXsystemsはSOHO向けのZFSベースのハイパーコンバージドソフトウェア「TrueNAS SCALE」とエンタープライズ向けの「TrueNAS」の開発を開始。^[91]

2010年1月、オラクル社はサン・マイクロシステムズ社を買収し、すぐにOpenSolarisディストリビューションとオープンソース開発モデルを廃止した。^{[95] [96]} 2010年8月、オラクル社はSolaris OS/Networkingリポジトリのソースコードへの公開アップデートの提供を中止し、事実上Solaris 11をクローズドソースの 独自OSに戻した。^[97]

Solaris と OpenSolaris を取り巻く状況の変化に対応して、Solaris のコアエンジニアによるコミュニティの取り組みとして、2010 年 8 月 3 日木曜日にウェビナー[ ^98]でillumosプロジェクトが開始されました。これは、Solaris のオープンソース版の開発を継続し、Sun によってまだオープンソース化されていない部分のオープンソース化を完了するための取り組みです。 ^[99] illumos は、カリフォルニア州で501(c)6業界団体として法人化された Illumos Foundation という財団として設立されました。当初の計画では、illumos はディストリビューションやフォークではないと明記されていました。しかし、Oracle が OpenSolaris の廃止を発表した後、Solaris ON の最終バージョンをフォークして、illumos を独自のオペレーティングシステムに進化させる計画が立てられました。^[100]そのため、OpenSolaris の一部として、ZFS のオープンソース版は illumos に不可欠なものとなりました。

ZFS は、Solaris だけでなく、多数のプラットフォームで広く使用されていました。そのため、2013 年に、ZFS のオープン ソース バージョンの開発作業の調整は、包括的なプロジェクトであるOpenZFSに引き継がれました。OpenZFS フレームワークにより、関心のあるすべての関係者が、コア ZFS コードベースを共同で開発しながら、ZFS が機能し、独自のシステム内で統合するために必要な特定の追加コードを個別に保守することができます。

注: 2005年のSolaris 10のリリース以降、Sunが開発していたSolarisバージョンのコード名は「Nevada」で、OpenSolarisのコードベースから派生したものです。「Solaris Nevada」は、最終的にSolaris 10の後継となる次世代Solaris OSのコード名であり、この新しいコードは、新しいOpenSolaris「Nevada」スナップショットビルドに次々と取り入れられました。^[101] OpenSolarisは現在は廃止されており、OpenIndianaが そこから分岐しました^{。 [102] [103] OpenSolarisの最終ビルド（b134）は、} Solaris 11 Express へのアップグレードパスとしてOracleによって公開されました（2010年11月12日）。

ZFS をサポートするオペレーティング システム、ディストリビューション、アドオン、サポートされる zpool バージョン、およびそれらがベースとする Solaris ビルド (存在する場合) のリスト:

• ファイルシステムの比較
• ファイルシステムのリスト
• バージョン管理ファイルシステム– バージョン管理ファイルシステムのリスト

• Fork Yeah! Illumos の台頭と発展 - Solaris の歴史、Sun によるオープン ソース化の決定、ZFS の作成、Oracle による買収後にクローズド ソース化されフォークされた経緯など、多くの内容を網羅したスライド ショーです。
• 最高のクラウド ファイル システムは、クラウドが存在する前に作成されました (2018 年 12 月 15 日にアーカイブ)
• SVMミラーリングとZFSミラーリングの比較
• EON ZFS ストレージ (NAS) ディストリビューション
• ファイルシステムのエンドツーエンドのデータ整合性: ZFS のケーススタディ
• ZFS – ゼタバイトファイルシステム (2013 年 2 月 28 日アーカイブ)
• ZFS と RAID-Z: Über-FS ですか?
• ZFS: ファイルシステムの最終形、Jeff Bonwick と Bill Moore 著 (2017 年 8 月 29 日アーカイブ)
• ZFS インテント ログ (ZIL) の視覚化、2013 年 4 月、Aaron Toponce 著
• OpenZFSを含むillumosの機能
  • 以前のウィキページにはさらに多くのリンクがあります: ZFS 入門、2014 年 9 月 15 日 (2018 年 12 月 30 日にアーカイブ)、illumosドキュメントの一部