ZFS – 日本語百科事典辞書

ZFS

その他の使用法については、ZFSを参照してくださいZFS（以前：Zettabyteファイルシステム）は、ファイルシステムとボリュームマネージャーを組み合わせたものです。これは、2001年にSun Microsystems Solaris オペレーティングシステムの一部として始まりました。ZFSを含むSolarisの大部分は、2005年から約5年間、OpenSolarisとしてオープンソースライセンスで公開され、その後OracleCorporationが買収したときにクローズドソースライセンスになりました。 2009/2010年の日曜日。2005年から2010年の間に、ZFSのオープンソースバージョンがLinux、Mac OS X（MacZFSとして継続）、およびFreeBSDに移植されました。。2010年には、illumosのプロジェクトはフォークZFSなどのオープンソースプロジェクトとして、その開発を継続するために、OpenSolarisのの最新バージョンを。2013年、オープンソースZFSの開発を調整するためにOpenZFSが設立されました。 OpenZFSはコアZFSコードを維持および管理しますが、ZFSを使用する組織は、ZFSをシステムに統合するために必要な特定のコードと検証プロセスを維持します。OpenZFSは、Unixライクなシステムで広く使用されています。 ZFS デベロッパー
サン・マイクロシステムズ（買収によりオラクル・コーポレーション2009年に）
で書かれている
C、C ++
OSファミリー
Unix（System Vリリース4）
動作状態
電流
ソースモデル
オープンソース/クローズドソースの混合
初回リリース
2006年6月; 15年前Solaris10 6/06（ “U2″）（2006-06）
最新のリリース
11.4 / 2018年8月28日; 2年前（2018-08-28）
マーケティング目標
ワークステーション、サーバー
プラットフォーム
SPARC、x86-64、IA-32（Solaris 11を除く）、PowerPC（Solaris 2.5.1のみ）
ライセンス
様々
公式ウェブサイト
www .oracle .com / solaris OpenZFS 初回リリース
2006年から2010年の間にさまざまなシステムに移植されました。2010年8月にOpenSolarisから分岐しました。11年前（2010-08）
安定したリリース
2.0.5
/ 2021年6月23日 ; 54日前（2021-06-23）
リポジトリ
github .com / openzfs / zfs
で書かれているオペレーティング・システム
OpenSolarisの、illumosの分布、OpenIndiana、FreeBSDでは、Mac OS X Serverの10.5（読み取り専用サポート）、NetBSDの、Linuxのサードパーティ製を経由してカーネルモジュール（ “LinuxでZFS”）またはZFS- FUSE、OSV
ライセンス
オープンソース CDDL
Webサイト
openzfs .org

コンテンツ
1 概要
2 歴史
2.1 サンマイクロシステムズ（2010年まで） 2.2 後の開発
3 特徴
3.1 概要 3.2 データの整合性 3.3 RAID（ “RAID-Z”）
3.3.1 ハードウェアRAIDコントローラーの回避
3.3.2 ZFSのアプローチ：RAID-Zとミラーリング
3.3.3 再銀メッキとスクラブ（アレイの同期と整合性チェック）
3.43.4 容量 3.5 暗号化 3.6 読み取り/書き込み効率 3.7 その他の機能
3.7.1 ストレージデバイス、スペア、およびクォータ
3.7.2 キャッシングメカニズム：ARC、L2ARC、トランザクショングループ、ZIL、SLOG、Special VDEV
3.7.2.1 特別なVDEVクラス
3.7.3 コピーオンライトトランザクションモデル
3.7.4 スナップショットとクローン
3.7.5 スナップショットの送受信
3.7.6 ダイナミックストライピング
3.7.7 可変ブロックサイズ
3.7.8 軽量ファイルシステムの作成
3.7.9 アダプティブエンディアン
3.7.10 重複排除
3.7.11 追加機能
4 制限事項
4.1 データ破損を防ぐための制限 4.2 ZFSに固有のその他の制限
5 データ復旧
6 OpenZFSおよびZFS
6.1 商用およびオープンソース製品 6.2 Oracle Corporation、クローズドソース、およびフォーク（2010年から）
7 バージョン履歴
7.1 ZFSをサポートするオペレーティングシステムのリスト
8 も参照してください
9 ノート
10 参考文献
11 参考文献
12 外部リンク

概要
保存されたデータの管理には、一般に2つの側面が含まれます。ハードドライブやSDカードなどの1つ以上のブロックストレージデバイスの物理ボリューム管理と、オペレーティングシステムから見た論理ブロックデバイスへのそれらの編成（多くの場合、ボリュームマネージャー、RAIDコントローラーが含まれます）、アレイマネージャー、または適切なデバイスドライバー）、およびこれらの論理ブロックデバイス（ファイルシステムまたはその他のデータストレージ）に保存されているデータとファイルの管理。
例：2台のハードドライブとSSDキャッシングディスクの
RAIDアレイは、デスクトップコンピューターに組み込まれているチップセットと
ファームウェアの一部である
IntelのRSTシステムによって制御されWindowsユーザーが自分のデータのNTFSでフォーマットされたドライブを含む、単一のボリュームとしてこれを見て、NTFSは、必ずしも、このようなキャッシュドライブへの書き込み/読み取りまたはとして必要とされる操作（の認識していない
RAIDアレイを再構築する場合ディスクに障害が発生しました）。個々のデバイスの管理と単一のデバイスとしてのそれらの表示は、その見かけのデバイスに保持されているファイルの管理とは異なります。
ZFSは、他のほとんどのストレージシステムとは異なり、これらの役割の両方を統合し、ボリュームマネージャーとファイルシステムの両方として機能するため、珍しいものです。したがって、物理ディスクとボリューム（状態とステータス、ボリュームへの論理配置を含む）の両方、およびそれらに保存されているすべてのファイルについて完全な知識がZFSは、（適切なハードウェアを条件として）物理エラーやハードウェアまたはオペレーティングシステムによる誤処理、または時間の経過とともに発生する可能性のあるビット腐敗イベントやデータ破損によってディスクに保存されたデータが失われないように設計されています。ストレージシステムは、ファイル管理またはディスク管理に関連するかどうかに関係なく、すべてのステップが検証、確認、必要に応じて修正、および最適化されるようにするために使用されます。これにより、ストレージコントローラーカードと個別のボリュームマネージャーおよびファイルマネージャーでは実現できません。
ZFSには、データセットおよびプールレベルのスナップショットとレプリケーションのメカニズムも含まれています。これには、FreeBSDドキュメントで「最も強力な機能」の1つとして説明されているスナップショットのクローン作成が含まれ、「スナップショット機能を備えた他のファイルシステムでも欠けている」機能がパフォーマンスを低下させることなく、非常に多数のスナップショットを作成できるため、リスクの高いシステム操作やソフトウェア変更の前にスナップショットを使用したり、本番（「ライブ」）ファイルシステム全体を1時間に数回完全にスナップショットしたりできます。ユーザーエラーまたは悪意のあるアクティビティによるデータ損失を軽減するため。スナップショットは「ライブ」でロールバックでき、非常に大きなファイルシステムでも以前のファイルシステムの状態を表示できるため、正式なバックアップおよび復元プロセスと比較して節約できます。スナップショットを複製して、新しい独立したファイルシステムを形成することもできます。プールレベルのスナップショット（「チェックポイント」と呼ばれる）を使用して、プールの構造全体に影響を与える可能性のある操作のロールバックを可能にしたり、データセット全体を追加または削除したりできます。

歴史
参照：
Solaris（オペレーティングシステム）、penSolaris、 penIndiana、
illumos、および
Sun Microsystems

サンマイクロシステムズ（2010年まで）
1987年、AT＆TコーポレーションとSunは、当時市場で最も人気のあったUnixバリアントであるBerkeley Software Distribution、UNIX System V、およびXenixを統合するプロジェクトで協力していることを発表しました。これがUnixSystem Vリリース4（SVR4）になりました。プロジェクトの名称の下でリリースされたSolarisの後継となった、SunOSの4（4.1のSunOSない。Xマイクロリリースはし遡及という名前のSolaris 1）。
ZFSは、Jeff Bonwick、Bill Moore 、MatthewAhrensが率いるSunのチームによって設計および実装されました。2004年9月14日に発表されましたが、開発は2001年に開始されました。 ZFSのソースコードは2005年10月31日にSolaris開発のメイントランクに統合され、開発者向けにリリースされました。2005年11月16日にOpenSolarisのビルド27。 2006年6月、SunはZFSがSolaris10のメインストリーム6/06アップデートに含まれていることを発表しました。
歴史的に、Solarisはプロプライエタリソフトウェアとして開発されました。サンマイクロシステムズは、オープンソースソフトウェアの強力な支持者でした。2005年6月、SunはCDDLライセンスの下でほとんどのコードベースをリリースし、OpenSolarisオープンソースプロジェクトを設立しました。 Sunはオープンソースソフトウェアの初期の支持者であり、OpenSolarisを使用して、Sunはソフトウェアを中心に開発者とユーザーのコミュニティを構築したいと考えていました。Solaris 10 6/06（ “U2″）で、SunはZFSファイルシステムを追加しました。次の5年間（2006年から2010年）、Sunは頻繁に新しい機能でZFSを更新し、ZFSはこのオープンソースライセンスの下でLinux、Mac OS X（MacZFSとして継続）およびFreeBSDに移植されました。
ある時点でこの名前は「ZettabyteFileSystem」の略であると言われていましたが、2006年までにその名前は略語とは見なされなくなりました。 ZFSファイルシステムは、最大256兆ゼタバイト（ZB）を格納できます。
2007年9月、NetAppは、ZFSがWrite Anywhere FileLayoutに関するNetAppの特許の一部を侵害していると主張してSunを提訴しました。サンは同年10月に反対を主張して反訴した。訴訟は2010年に非公開の和解で終了しました。

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

特徴

概要
ZFSに固有の機能の例は次のとおりです。
データの長期保存、データ損失ゼロ、高い構成可能性を備えた無期限にスケーリングされたデータストアサイズ向けに設計されています。
すべてのデータとメタデータの階層的なチェックサム。ストレージシステム全体が使用時に検証され、正しく保存されていることを確認できるか、破損している場合は修正できることを確認します。チェックサムは、ブロック自体ではなく、ブロックの親ブロックとともに保存されます。これは、チェックサム（保持されている場合）がデータとともに保存される多くのファイルシステムとは対照的であるため、データが失われたり破損したりすると、チェックサムも失われたり正しくなかったりする可能性が
重要なファイルや構造のデータ破損から回復する機能を向上させるために、ユーザーが指定した数のデータやメタデータのコピー、または選択したタイプのデータを保存できます。
エラーまたは不整合が発生した場合に、状況によっては、ファイルシステムおよびデータに対する最近の変更の自動ロールバック。
データの不整合の自動化された（通常は）サイレントな自己修復と、データが再構築可能なすべてのエラーについて、検出された場合の書き込みエラー。データは、次のすべてを使用して再構築できます。各ブロックの親ブロックに格納されているエラー検出および訂正チェックサム。ディスクに保持されているデータの複数のコピー（チェックサムを含む）。発生するはずだったが発生しなかった（電源障害後）書き込みについて、SLOG（ZIL）に記録された書き込み意図。RAID / RAID-Zディスクおよびボリュームからのパリティデータ。ミラーリングされたディスクおよびボリュームからのデータのコピー。
標準RAIDレベルおよび追加のZFSRAIDレイアウト（「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、 XFS、JFS、NTFSなど）もハードウェアRAID（データの整合性に問題がある）もデータに対する十分な保護を提供していませんでした。破損の問題。初期の調査によると、ZFSは以前の取り組みよりもデータを保護します。 UFS よりも高速であり、その代替品と見なすことができます。
ZFS内では、データの整合性は、ファイルシステムツリー全体でフレッチャーベースのチェックサムまたはSHA-256ハッシュを使用することによって実現されます。データの各ブロックはチェックサムされ、チェックサム値は実際のブロック自体ではなく、そのブロックへのポインターに保存されます。次に、ブロックポインタがチェックサムされ、値がそのポインタに保存されます。このチェックサムは、ファイルシステムのデータ階層からルートノードまで続きます。ルートノードもチェックサムされ、マークルツリーが作成されます。実行中のデータ破損またはファントム読み取り/書き込み（データの書き込み/読み取りチェックサムは正しく、実際には間違っています）は、チェックサムをデータと一緒に保存するため、ほとんどのファイルシステムでは検出できません。ZFSは、各ブロックのチェックサムをその親ブロックポインターに格納するため、プール全体が自己検証されます。
ブロックがアクセスされると、それがデータであるかメタデータであるかに関係なく、そのチェックサムが計算され、保存されている「あるべき」チェックサム値と比較されます。チェックサムが一致する場合、データはプログラミングスタックを介して、それを要求したプロセスに渡されます。値が一致しない場合、ストレージプールがデータの冗長性を提供していれば（内部ミラーリングなど）、データのコピーに損傷がなく、チェックサムが一致していると仮定して、ZFSはデータを修復できます。オプションで、copys = 2（または
copys = 3以上）を指定することにより、プール内の冗長性を追加することができます。これは、データがディスクに2回（または3回）保存され、実質的に半分（または、以下のための
コピー= 3三分の一）にディスクの記憶容量を削減。さらに、プールを管理するためにZFSによって使用されるいくつかの種類のデータは、デフォルトのcopys = 1設定であっても、安全のためにデフォルトで複数回保存されます。
破損したデータの他のコピーが存在するか、チェックサムとパリティデータから再構築できる場合、ZFSはデータのコピーを使用して（またはRAIDリカバリメカニズムを介して再作成し）、チェックサムを再計算します。理想的には、元のデータが再現されます。期待値。データがこの整合性チェックに合格すると、システムはすべての障害のあるコピーを正常なデータで更新でき、冗長性が復元されます。
ZFSはエラー修正RAMを備えたエンタープライズ品質のハードウェアで実行されることが期待されているため、ARCにキャッシュされたデータなど、メモリに保持されているデータの整合性はデフォルトではチェックされませんが、メモリ内データをチェックする機能は存在し、「デバッグフラグ」を使用して有効にします。

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

ハードウェアRAIDコントローラーの回避
ZFSはハードウェアRAIDデバイスで動作できますが、すべてのストレージデバイスにrawアクセスでき、ディスクがハードウェア、ファームウェア、またはその他の「ソフト」を使用してシステムに接続されていない場合、ZFSは通常、より効率的に動作し、データの保護が強化されます。 RAID、または通常のZFSからディスクへのI / Oパスを変更するその他のコントローラー。これは、ZFSが正直なビューをディスクに依存して、データが安全に書き込まれたことが確認された瞬間を判断し、キャッシュ、キャッシュフラッシュ、およびディスク処理の使用を最適化するように設計された多数のアルゴリズムを備えているためです。
サードパーティのデバイスがキャッシュを実行するか、ドライブを単一のシステムとしてZFSに提示する場合、またはZFSが依存する低レベルのビューがない場合、システムのパフォーマンスが最適化されず、障害を防止できない可能性がはるかに高くなります。 ZFSによって、またはZFSによって迅速または完全に回復されます。たとえば、ハードウェアRAIDカードが使用されている場合、ZFSはディスクの状態や、RAIDアレイが劣化しているか再構築しているかを判断できない可能性があり、すべてのデータ破損を認識していない可能性があり、ディスク間でデータを最適に配置できない可能性が、選択的な修復のみを行い、修復と継続的な使用のバランスを制御します。ハードウェアRAIDカードが干渉するため、通常は修復できたとしても修復できない場合がRAIDコントローラーは通常、コントローラーに依存するデータをドライブに追加し、ソフトウェアRAIDがユーザーデータにアクセスできないようにします。互換性のあるハードウェアRAIDコントローラーでデータを読み取ることは可能ですが、常に可能であるとは限りません。コントローラーカードに障害が発生した場合、交換が利用できない可能性があり、他のカードはメーカーのカスタムデータを理解できない可能性が新しいカードのアレイを管理および復元するために必要です。
したがって、RAIDカードなどを使用してリソースと処理をオフロードし、パフォーマンスと信頼性を向上させる他のほとんどのシステムとは異なり、ZFSでは、通常、システムのパフォーマンスと信頼性が低下するため、これらの方法を使用しないことを強くお勧めします。
ディスクをRAIDまたはその他のコントローラーを介して接続する必要がある場合は、プレーンHBA（ホストアダプター）またはファンアウトカードを使用するか、カードをJBODモードで構成する（つまり、RAIDおよびキャッシュ機能をオフにする）ことをお勧めします。接続されていますが、ZFSからディスクへのI / O経路は変更されJBODモードのRAIDカードは、キャッシュがある場合、またはその設計によっては干渉する可能性があり、（多くのエネルギー効率の高い民生用ハードドライブで見られるように）時間内に応答しないドライブを切り離す可能性がそのため、ドライブのドロップアウトを防ぐために時間制限エラー回復（TLER）/ CCTL / ERC対応ドライブが必要になる場合があるため、RAID機能が無効になっていてもすべてのカードが適しているわけではありません。

ZFSのアプローチ：RAID-Zとミラーリング
ZFSは、ハードウェアRAIDの代わりに「ソフト」RAIDを採用し、RAID-Z（RAID 5などのパリティベース）とディスクミラーリング（RAID 1と同様）を提供します。スキームは非常に柔軟です。
RAID-ZはRAID-5と同様のデータ/パリティ分散スキームですが、動的ストライプ幅を使用します。ブロックサイズに関係なく、すべてのブロックが独自のRAIDストライプであるため、すべてのRAID-Z書き込みはフルストライプ書き込みになります。これをZFSのコピーオンライトトランザクションセマンティクスと組み合わせると、書き込みホールエラーが排除されます。RAID-Zは、通常の読み取り-変更-書き込みシーケンスを実行する必要がないため、従来のRAID5よりも高速です。
すべてのストライプのサイズが異なるため、RAID-Z再構築では、ファイルシステムメタデータをトラバースして、実際のRAID-Zジオメトリを決定する必要がこれは、ファイルシステムとRAIDアレイが別々の製品である場合は不可能ですが、データの論理構造と物理構造の統合ビューがある場合は実現可能になります。メタデータを通過するということは、ZFSが256ビットのチェックサムに対してすべてのブロックを検証できることを意味しますが、従来のRAID製品は通常これを実行できません。
RAID-Zは、ディスク全体の障害を処理するだけでなく、サイレントデータの破損を検出して修正し、「自己修復データ」を提供します。RAID-Zブロックを読み取るときに、ZFSはそれをチェックサムと比較し、データディスクが正しい答えを返さない場合、ZFSはパリティを読み取り、どのディスクが不良データを返したかを判断します。次に、破損したデータを修復し、適切なデータをリクエスターに返します。
RAID-Zとミラーリングには、特別なハードウェアは必要ありません。信頼性のためにNVRAMは必要ありません。また、優れたパフォーマンスやデータ保護のために書き込みバッファリングも必要ありません。RAID-Zを使用すると、ZFSは安価なコモディティディスクを使用して高速で信頼性の高いストレージを提供します。
5つの異なるRAID-Zモードがあります：ストライピング（RAID 0と同様、冗長性を提供しません）、RAID-Z1（RAID 5と同様、1つのディスクに障害が発生する可能性があります）、RAID-Z2（RAID 6と同様、2つのディスクが失敗）、RAID-Z3（RAID 7 構成、3つのディスクの障害を許可）、およびミラーリング（RAID 1と同様に、1つを除くすべてのディスクの障害を許可）。
RAID-Z3の必要性は、マルチテラバイト容量のドライブがより一般的になるにつれて、2000年代初頭に発生しました。この容量の増加は、対応するスループット速度の増加なしに、ドライブの障害によるアレイの再構築が完了するまでに「数週間または数か月」かかる可能性があることを意味します。この間、アレイ内の古いディスクは追加のワークロードによってストレスを受け、データの破損やドライブの障害が発生する可能性がRAID-Z3は、パリティを増やすことで、冗長性を高めるだけでデータ損失の可能性を減らします。

再銀メッキとスクラブ（アレイの同期と整合性チェック）
ZFSには、fsck（ファイルシステム用の標準のUnixおよびLinuxデータチェックおよび修復ツール）に相当するツールはありません。代わりに、ZFSには、すべてのデータを定期的に検査し、サイレント破損やその他の問題を修復するスクラブ機能が組み込まれています。いくつかの違いは次のとおりです。
fsckはオフラインファイルシステムで実行する必要がつまり、ファイルシステムはマウント解除する必要があり、修復中は使用できません。一方、scrubはマウントされたライブファイルシステムで使用するように設計されており、ZFSファイルシステムをオフラインにする必要はありません。
fsckは通常、メタデータ（ジャーナルログなど）のみをチェックし、データ自体はチェックしません。つまり、fsckを実行した後でも、データは保存されている元のデータと一致しない可能性が
チェックサムがデータとともに保存されている場合（多くのファイルシステムの場合）、fsckは常にデータを検証および修復できるとは限りません。これは、チェックサムも破損しているか、読み取れない可能性があるためです。ZFSは常にチェックサムを検証するデータとは別に保存し、信頼性とボリュームを修復するためのスクラブの機能を向上させます。ZFSは、データの複数のコピーも格納します。特に、メタデータには4つまたは6つ以上のコピー（ディスクごとに複数のコピー、ボリュームごとに複数のディスクミラー）が含まれる場合があり、ボリュームへの広範な損傷を検出して修復するスクラブの機能が大幅に向上します。 fsckと比較して。
scrubは、メタデータとデータを含むすべてをチェックします。この効果は、fsckとスクラブ時間を比較することで確認できます。大規模なRAIDのfsckが数分で完了する場合がこれは、メタデータのみがチェックされたことを意味します。大規模なRAIDですべてのメタデータとデータをトラバースするには、何時間もかかります。これはまさにスクラブが行うことです。
Sun / Oracleからの公式の推奨事項は、エンタープライズレベルのディスクを月に1回スクラブし、より安価なコモディティディスクを週に1回スクラブすることです。

容量
ZFSは128ビットファイルシステム、が1.84×10対処することができるので、19のような64ビットのシステムよりも倍以上のデータはBtrfsを。ZFSの上限は非常に大きくなるように設計されているため、実際には決して遭遇することはありません。例えば、完全2つのを有する単一のzpool移入128 3×10必要とするデータのビット24 TBのハードディスクドライブ。
ZFSの理論上の制限は次のとおりです。
16エクスビバイト（2 64バイト）：単一ファイルの最大サイズ
2 48：個々のディレクトリのエントリ数
16エクスビバイト：任意の属性の最大サイズ
2 56：ファイルの属性の数（実際には、ディレクトリ内のファイルの数は2 48に制限されています）
256兆ゼビバイト（2 128バイト）：任意のzpoolの最大サイズ
2 64：任意のzpool内のデバイスの数
2 64：zpool内のファイルシステムの数
2 64：システム内のzpoolの数

暗号化
Oracle Solarisでは、ZFS の暗号化機能がI / Oパイプラインに組み込まれています。書き込み中に、ブロックはこの順序で圧縮、暗号化、チェックサム、および重複排除される場合が暗号化のポリシーは、データセット（ファイルシステムまたはZVOL）が作成されるときにデータセットレベルで設定されます。ユーザー/管理者が提供するラッピングキーは、ファイルシステムをオフラインにすることなくいつでも変更できます。デフォルトの動作では、ラッピングキーはすべての子データセットに継承されます。データ暗号化キーは、データセットの作成時にランダムに生成されます。子孫データセット（スナップショットとクローン）のみがデータ暗号化キーを共有します。クローン用に、またはいつでも新しいデータ暗号化キーに切り替えるコマンドが提供されます。これは、既存のデータを再暗号化せず、代わりに暗号化されたマスターキーメカニズムを利用します。
2019年の時点で、暗号化機能は、DebianおよびUbuntuLinuxディストリビューションで利用可能なOpenZFS0.8.0にも完全に統合されています。

読み取り/書き込み効率
ZFSは、プールのパフォーマンスを一般的に最大化する方法で、プール内のすべてのvdev（および各vdev内のすべてのデバイス）にデータストレージを自動的に割り当てます。ZFSは、プールに追加された新しいディスクが追加されたときにそれを考慮に入れるように、書き込み戦略も更新します。
原則として、ZFSは各vdevの空き領域に基づいてvdev全体に書き込みを割り当てます。これにより、すでにデータが比例して少ないvdevには、新しいデータを保存するときに、より多くの書き込みが与えられます。これは、プールがより使用されるようになっても、一部のvdevがいっぱいになり、限られた数のデバイスで書き込みが強制されるという状況が発生しないようにするのに役立ちます。また、データが読み取られると（ほとんどの場合、読み取りは書き込みよりもはるかに頻繁に行われます）、データのさまざまな部分をできるだけ多くのディスクから同時に読み取ることができるため、読み取りパフォーマンスが大幅に向上します。したがって、原則として、プールとvdevを管理し、新しいストレージを追加して、プール内の一部のvdevがほぼ満杯になり、他のvdevがほぼ空になるという状況が発生しないようにする必要がこれにより、プールの効率が低下します。

その他の機能

ストレージデバイス、スペア、およびクォータ
プールには、障害のあるディスクを補うためのホットスペアを含めることができます。ミラーリングする場合、ブロックデバイスを物理シャーシに従ってグループ化できるため、シャーシ全体に障害が発生した場合でもファイルシステムを継続できます。
ストレージプールの構成は、類似のデバイスに限定されませんが、アドホックで異種のデバイスのコレクションで構成できます。これらのデバイスは、ZFSがシームレスにプールし、その後、必要に応じてさまざまなファイルシステムにスペースを割り当てます。任意のストレージデバイスタイプを既存のプールに追加して、サイズを拡張できます。
すべてのvdevのストレージ容量は、zpool内のすべてのファイルシステムインスタンスで使用できます。クォータは、ファイル・システム・インスタンスが占有できるスペースの量を制限するように設定することができ、かつ予約はスペースがファイル・システム・インスタンスに利用可能になることを保証するために設定することができます。

キャッシングメカニズム：ARC、L2ARC、トランザクショングループ、ZIL、SLOG、Special VDEV
ZFSは、ディスクキャッシュのさまざまなレイヤーを使用して、読み取りおよび書き込み操作を高速化します。理想的には、すべてのデータをRAMに保存する必要がありますが、通常はコストがかかりすぎます。したがって、データは階層に自動的にキャッシュされ、パフォーマンスとコストを最適化します。これらはしばしば「ハイブリッドストレージプール」と呼ばれます。頻繁にアクセスされるデータはRAMに保存され、あまり頻繁にアクセスされないデータは、ソリッドステートドライブ（SSD）などの低速のメディアに保存できます。頻繁にアクセスされないデータはキャッシュされず、低速のハードドライブに残されます。古いデータが突然大量に読み取られた場合、ZFSはそれをSSDまたはRAMに自動的に移動します。
ZFSキャッシングメカニズムには、読み取りと書き込み用にそれぞれ1つが含まれ、いずれの場合も、2つのレベルのキャッシングが存在できます。1つはコンピューターメモリ（RAM）に、もう1つは高速ストレージ（通常はソリッドステートドライブ（SSD））にあり、合計4つです。キャッシュ。
保管場所キャッシュの読み取りキャッシュの書き込み
第1レベルのキャッシュ RAM内アダプティブリプレースメントキャッシュ（ARC）アルゴリズムのバリアントを使用しているため、ARCとして知られています。RAMは常にキャッシュに使用されるため、このレベルは常に存在します。ARCアルゴリズムの効率は、ARCサイズが十分に大きい場合、ディスクにアクセスする必要がないことを意味します。RAMが小さすぎると、ARCはほとんどありません。この場合、ZFSは常に基盤となるディスクにアクセスする必要があり、パフォーマンスに大きな影響を与えます。
「トランザクショングループ」によって処理されます–書き込みは、指定された制限までの短い期間（通常は5〜30秒）で照合されます。各グループは、理想的には次のグループが照合されている間にディスクに書き込まれます。これにより、停電やハードウェア障害時に最新のトランザクションのデータがわずかに失われるリスクがありますが、基盤となるディスクの書き込みをより効率的に整理できます。実際には、電力損失のリスクはZFS書き込みジャーナリングとSLOG / ZILの第2層書き込みキャッシュプール（以下を参照）によって回避されるため、書き込み障害が2番目の完全な損失と同時に発生した場合にのみ書き込みが失われます。層SLOGプール、および同期書き込みとSLOGの使用に関連する設定がそのような状況が発生することを可能にする方法で設定されている場合のみ。データが書き込むよりも速く受信された場合、データの受信はディスクが追いつくまで一時停止されます。
第2レベルのキャッシュ高速ストレージデバイス（現在のバージョンのZFSでは中断することなく「ライブ」システムに追加または削除できますが、古いバージョンでは常にそうであるとは限りません） L2ARC（「レベル2 ARC」）と呼ばれ、オプションです。ZFSは、可能な限り多くのデータをL2ARCにキャッシュします。これは、多くの場合、数十ギガバイトまたは数百ギガバイトになる可能性がまた、重複排除テーブル全体をL2ARCにキャッシュできる場合、L2ARCは重複排除を大幅に高速化します。L2ARCを空から完全に移入するのに数時間かかる場合があります（ZFSがどのデータが「ホット」でキャッシュされるべきかを決定する前に）。L2ARCデバイスが失われると、すべての読み取りがディスクに送信されるため、パフォーマンスが低下しますが、それ以外は何も起こりません（データが失われることはありません）。
SLOGまたはZIL（「ZFSインテントログ」）として知られています–これらの用語はしばしば誤って使用されます。SLOG（セカンダリログデバイス）は、システムの問題が発生した場合に書き込みを記録するための、別のデバイス上のオプションの専用キャッシュです。SLOGデバイスが存在する場合は、第2レベルのログとしてZFSインテントログに使用されます。個別のキャッシュデバイスが提供されていない場合は、代わりにメインストレージデバイスにZILが作成されます。したがって、SLOGは、技術的には、プールを高速化するために、ZILがオフロードされる専用ディスクを指します。厳密に言えば、ZFSはSLOGデバイスを使用してディスク書き込みをキャッシュしません。むしろ、SLOGを使用して、書き込みが永続ストレージメディアにできるだけ早くキャプチャされるようにします。これにより、停電や書き込み障害が発生した場合に、書き込みが確認されたデータが失われることはありません。SLOGデバイスを使用すると、ZFSは書き込みを迅速に保存し、HDDなどのはるかに低速なストレージデバイスの場合でも、書き込みとしてすばやく報告できます。通常のアクティビティでは、SLOGが参照または読み取られることはなく、キャッシュとしても機能しません。その目的は、最終的な書き込みが失敗した場合に備えて、照合と「書き込み」にかかる数秒間の飛行中のデータを保護することです。すべてがうまくいけば、ストレージプールは次の5〜60秒以内のある時点で更新され、現在のトランザクショングループがディスクに書き出されます（上記を参照）。その時点で、SLOGに保存された書き込みは単純に次のようになります。無視され、上書きされます。書き込みが最終的に失敗した場合、またはシステムでクラッシュや障害が発生して書き込みができなくなった場合、ZFSは、SLOG（読み取り時のみ）を読み戻すことで、書き込みが確認されたすべての書き込みを識別し、これを使用できます。データ損失を完全に修復します。これは、多数の同期書き込みが行われる場合（ESXi、NFS、および一部のデータベースなど）、クライアントがアクティビティを続行する前に書き込みが成功したことを確認する必要がある場合に重要になります。SLOGを使用すると、ZFSは、データストレージの状態に関してクライアントを誤解させるリスクなしに、毎回メインストアに書き込む必要がある場合よりもはるかに迅速に書き込みが成功したことを確認できます。SLOGデバイスがない場合、メインデータプールの一部が同じ目的で使用されますが、これは低速です。ログデバイス自体が失われると、最新の書き込みが失われる可能性があるため、ログデバイスをミラーリングする必要が以前のバージョンのZFSでは、ログデバイスが失われると、zpool全体が失われる可能性がありましたが、現在はそうではありません。したがって、別のログデバイスを使用する場合は、ZFSをアップグレードする必要が
他の多くのキャッシュ、キャッシュ分割、およびキューもZFS内に存在します。たとえば、各VDEVには独自のデータキャッシュがあり、ARCキャッシュは、ユーザーが保存したデータとZFSが使用するメタデータに分割され、これらのバランスを制御します。

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

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

スナップショットとクローン
コピーオンライトの利点は、ZFSが新しいデータを書き込むときに、古いデータを含むブロックを保持できるため、ファイルシステムのスナップショットバージョンを維持できることです。ZFSスナップショットは一貫性があり（単一の時点で存在していたデータ全体を反映します）、スナップショットを構成するすべてのデータがすでに保存されており、ストレージプール全体が1時間に数回スナップショットされることが多いため、非常に迅速に作成できます。。また、変更されていないデータはファイルシステムとそのスナップショット間で共有されるため、スペース効率も高くなります。スナップショットは本質的に読み取り専用であり、作成後に変更されないようにしますが、バックアップの唯一の手段として信頼するべきではありません。スナップショット全体を復元でき、スナップショット内のファイルとディレクトリも復元できます。
書き込み可能なスナップショット（「クローン」）も作成できるため、ブロックのセットを共有する2つの独立したファイルシステムが作成されます。クローンファイルシステムのいずれかに変更が加えられると、それらの変更を反映するために新しいデータブロックが作成されますが、クローンがいくつ存在しても、変更されていないブロックは引き続き共有されます。これは、コピーオンライトの原則の実装です。

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

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

可変ブロックサイズ
ZFSは可変サイズのブロックを使用し、デフォルトサイズは128KBです。特定のワークロードは大きなブロックではうまく機能しないため、利用可能な機能により、管理者は使用される最大ブロックサイズを調整できます。データ圧縮が有効になっている場合、可変ブロックサイズが使用されます。ブロックを圧縮して小さいブロックサイズに収めることができる場合は、ディスクで小さいサイズを使用して、使用するストレージを減らし、IOスループットを向上させます（ただし、圧縮および解凍操作でのCPU使用量が増加します）。

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

アダプティブエンディアン
プールとそれに関連するZFSファイルシステムは、異なるバイトオーダーを実装するシステムを含む、異なるプラットフォームアーキテクチャ間で移動できます。ZFSブロックポインタ形式は、エンディアンに適応した方法でファイルシステムメタデータを格納します。個々のメタデータブロックは、ブロックを書き込むシステムのネイティブバイト順序で書き込まれます。読み取るときに、格納されているエンディアンがシステムのエンディアンと一致しない場合、メタデータはメモリ内でバイトスワップされます。
これは保存されたデータには影響しません。POSIXシステムで通常行われているように、ファイルはアプリケーションには単純なバイト配列として表示されるため、データを作成および読み取るアプリケーションは、基盤となるシステムのエンディアンに依存しない方法でそれを行う責任が

重複排除
データ重複排除機能は2009年10月末にZFSソースリポジトリに追加され、関連するOpenSolaris ZFS開発パッケージは2009年12月3日（ビルド128）から利用可能になりました。
重複排除を効果的に使用するには、大容量のRAMが必要になる場合が推奨される範囲は、ストレージ1TBごとに1〜5GBのRAMです。重複排除に必要なメモリの正確な評価は、プール内の一意のブロックの数、および保存に必要なディスクとRAM（「コア」）のバイト数を参照することによって行われます。各レコード-これらの数値は、zpoolやzdbなどの組み込みコマンドによって報告されます。物理メモリが不足している、またはZFSキャッシュが不足していると、重複排除を使用するときに仮想メモリがスラッシングし、パフォーマンスが低下したり、完全なメモリ不足が発生したりする可能性が重複排除は書き込み時に発生するため、CPUに非常に負荷がかかり、システムの速度が大幅に低下する可能性も
他のストレージベンダーは、ZFSの修正バージョンを使用して、非常に高いデータ圧縮率を実現しています。2012年の2つの例は、GreenBytes とTegileでした。 2014年5月、オラクルはZFS重複排除およびレプリケーションテクノロジーのためにGreenBytesを購入しました。
上記のように、重複排除は、システムとデータがこの省スペース技術に適している特定の状況を除いて、リソース要件が大きく（特にRAM）、パフォーマンスに影響を与える（特に書き込み時）ため、通常は推奨されません。

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

制限事項
ZFSファイルシステムにはいくつかの制限が

データ破損を防ぐための制限
特にZFSに焦点を当てて、データ破損を検出および防止するファイルシステムの機能を調査した2010年の調査の著者は、ZFS自体がストレージデバイス上のデータエラーの検出と修正に効果的であるが、RAM内のデータは「安全」であり、エラーが発生しにくい。この調査では、「メモリ内の1ビットの反転により、実行のわずかではあるが無視できない割合で障害が発生し、ディスクに不良データをコミットする確率は0％から3.6％まで変化します（ワークロードに応じて）」とコメントしています。また、ZFSがページをキャッシュするか、メタデータのコピーをRAMに保存する場合、またはディスクに書き込むためにデータを「ダーティ」キャッシュに保持する場合、チェックサムが使用時点のデータと一致するかどうかのテストは行われません。このリスクの多くは、次の2つの方法のいずれかで軽減できます。
著者によると、使用してECC RAMを。ただし、作成者は、ページキャッシュとヒープに関連するエラー検出を追加すると、ZFSが特定のクラスのエラーをより堅牢に処理できるようになると考えました。
ZFSの主要なアーキテクトの1人であるMattAhrensは、これらの懸念に対処するZFS_DEBUG_MODIFYフラグ（zfs_flags = 0x10）を使用して、メモリ内のデータのチェックサムを有効にするオプションがあると説明しています。

ZFSに固有のその他の制限
容量の拡張は通常、ディスクのグループをトップレベルのvdevとして追加することによって実現されます：シンプルデバイス、RAID-Z、RAID Z2、RAID Z3、またはミラーリング。新しく書き込まれたデータは、使用可能なすべてのvdevを動的に使用し始めます。アレイ内の各ドライブをより大きなドライブと繰り返し交換し、ZFSが自己回復するのを待つことで、アレイを拡張することもできます。修復時間は、ディスクサイズではなく、保存されている情報の量によって異なります。
Solaris 10 Update11およびSolaris11.2の時点では、ホットスペア、キャッシュ、およびログデバイスを除いて、プール内の最上位のvdevの数を減らすことも、プールの容量を減らすこともできませんでした。この機能は2007年に開発中であると言われていました。 vdevの削減を可能にする拡張機能はOpenZFSで開発中です。非冗長トップレベルvdevを削除することによるオンライン縮小は、2018年8月にリリースされたSolaris 11.4 および2019年5月にリリースされたOpenZFS（ZoL）0.8以降でサポートされています。
2008年の時点では、ディスクを列としてRAID Z、RAID Z2、またはRAID Z3vdevに追加することはできませんでした。ただし、代わりに新しいRAID Z vdevを作成して、zpoolに追加することができます。
RAID 51（RAID 5グループのミラー）など、一部の従来のネストされたRAID構成は、サードパーティのツールがないとZFSで構成できません。Vdevは、デフォルトのZFS管理コマンドを使用して、他のvdevではなく、rawディスクまたはファイルでのみ構成できます。ただし、ZFSプールはvdev全体にストライプ（RAID 0）を効果的に作成するため、RAID50またはRAID60と同等のものが一般的です。
トップレベルvdev内のデバイス数を再構成するには、データをオフラインでコピーし、プールを破棄し、新しいトップレベルvdev構成でプールを再作成する必要がただし、既存のミラーに冗長性を追加することはいつでも可能です。または、すべてのトップレベルvdevが十分な冗長性を備えたミラーである場合、zpool split コマンドを使用して、プール内の各トップレベルvdevからvdevを削除し、同一データで2番目のプールを作成できます。
ZFS RAIDが適切に構成されていない場合、ZFSストレージプールのIOPSパフォーマンスが低下する可能性がこれは、何らかの形ですべてのタイプのRAIDに適用されます。zpoolが、たとえばRAID Z2で8つのディスクとして構成されたディスクの1つのグループのみで構成されている場合、IOPSのパフォーマンスは単一のディスクのパフォーマンスになります（書き込み速度は6つのディスクに相当しますが、ランダムな読み取り速度は次のようになります。単一のディスク）。ただし、このIOPSパフォーマンスの問題を軽減する方法はいくつかたとえば、SSDをL2ARCキャッシュとして追加すると、IOPSが100.000に増加する可能性が要するに、RAID Zを使用している場合、zpoolはvdevの複数のグループで構成され、各vdevは8〜12個のディスクで構成されます。IOPSのため、単一の大きなvdev、たとえば20個のディスクでzpoolを作成することはお勧めしません。パフォーマンスは単一ディスクのパフォーマンスになります。これは、復元時間が非常に長くなることも意味します（将来の大型ドライブでは数週間になる可能性があります）。
ZFS RAIDで障害が発生したディスクの再シルバー化（修復）には時間がかかる場合がありますが、これはZFSに固有のものではなく、何らかの形ですべてのタイプのRAIDに適用されます。これは、非常に大きなボリュームが修復されるか、重大なデータの破損または障害の後に完全な冗長性に戻るまでに数日かかる可能性があることを意味します。この間に、特に修復によってシステム全体に追加のストレスがかかるため、2番目のディスク障害が発生する可能性が。つまり、RAID Z1（RAID 5と同様）など、単一のディスク障害の回復のみを許可する構成は避ける必要がしたがって、大きなディスクの場合は、RAID Z2（2つのディスクに障害が発生することを許可する）またはRAID Z3（3つのディスクに障害が発生することを許可する）を使用する必要が ZFS RAIDは、ディスクを交換するときにライブデータとメタデータを再構築するだけで、空白ブロックとガベージブロックを含むディスク全体を再構築しないという点で、従来のRAIDとは異なります。つまり、部分的にしか満たされていないZFSプールのメンバーディスクを交換すると、従来のRAIDと比較して、それに比例して時間がかかりません。

データ復旧
歴史的に、ZFSには、破損したファイルシステムを修復するためのfsckなどのツールは付属しこれは、ファイルシステム自体が、データのストレージと冗長性の設計に十分な注意を払って構築されている限り、自己修復するように設計されているためです。ハードウェアの質の悪さ、不十分な設計や冗長性、または不幸な事故のためにプールが危険にさらされ、ZFSがプールをマウントできなかった場合、従来、エンドユーザーが保存されたデータの部分的なサルベージを試みることを可能にするツールはありませんでした。。これにより、オンラインフォーラムにスレッドが作成され、ZFS開発者は、不適切な設計や不十分なシステム管理のためにデータの損失に直面して、ホームユーザーやその他の小規模ユーザーにアドホックヘルプを提供しようとすることがありました。
最新のZFSは、この状況を時間の経過とともに大幅に改善しており、引き続き改善しています。
キャッシュデバイスの削除または突然の障害により、プールが失われることはなくなりました。（最悪の場合、ZILが失われるとごく最近のトランザクションが失われる可能性がありますが、ZILは通常、数秒以上の最近のトランザクションを保存しません。L2ARCキャッシュが失われてもデータに影響はありません。）
プールがマウントできない場合、最新バージョンのZFSは、コンテンツへの最新の変更の一部を失うことを犠牲にして、回復できるプールの最新の一貫したポイントを識別しようとします。コピーオンライトとは、最上位のレコードやメタデータを含む古いバージョンのデータが、置き換えられても存在する可能性があることを意味します。その場合、プールはそれらに基づいて一貫した状態に戻すことができます。データが古いほど、少なくとも一部のブロックが上書きされ、一部のデータが回復不能になる可能性が高くなります。そのため、ある時点で、プールを巻き戻す機能に制限が
非公式には、ZFSがプールをマウントできない理由を調査し、プールを強制的にマウントするために必要な手動の変更についてユーザーまたは開発者をガイドするツールが存在します。これには、zdb（ZFSデバッグ）を使用してプール内の有効なインポート可能なポイントを見つける、dtraceなどを使用してマウントの失敗の原因となる問題を特定する、またはマウントプロセスを中止して損傷したプールのマウントを許可するヘルスチェックを手動でバイパスすることが含まれます。
2018年3月の時点で、大幅に強化されたさまざまなメソッドがOpenZFS内で徐々に展開されています。これらには以下が含まれます：
破損したプールの問題の診断と修正を簡素化するための、コードのリファクタリング、およびマウントの失敗に関するより詳細な診断とデバッグの情報。
保存されたプール構成を信頼または不信にする機能。これは特に強力です。トップレベルのvdevが見つからないか障害がある場合でも、トップレベルのデータが疑われる場合でもプールをマウントでき、その変更が問題に関連している場合は、プール構成の変更を超えて巻き戻すことができます。破損したプールがマウントされると、安全のために読み取り可能なファイルをコピーできます。プールの他の場所に保存されているコピーを使用することで、vdevが欠落している場合でもデータを再構築できることが判明する場合が
あるプールで必要なディスクが誤って削除されて別のプールに追加され、最初のプールに関連するメタデータが失われ、読み取り不能になる状況を修正する機能。

OpenZFSおよびZFS
Oracle Corporationは、2010年にSunを買収した後、ZFSとOpenSolarisの両方の公開開発を中止しました。一部の開発者は、OpenSolarisの最後のパブリックリリースをIllumosプロジェクトとしてフォークしました。ZFSには大きな利点があるため、さまざまな機能とコマンドを備えたいくつかの異なるプラットフォームに移植されています。開発作業を調整し、断片化を回避するために、OpenZFSは2013年に設立されました。
ZFSの主要なアーキテクトの1人であるMattAhrensによると、2019年の時点でOpenZFSでは元のOpenSolaris ZFSコードの50％以上がコミュニティの貢献に置き換えられており、「OracleZFS」と「OpenZFS」は政治的および技術的に互換性がありません。

商用およびオープンソース製品
あなたはそれに追加することによって助けることができます
2008：Sunは、ZFSベースの7000シリーズストレージアプライアンスのラインを出荷しました。
2013年：オラクルはZFSベースのファイラーのZS3シリーズを出荷し、そのうちの1つでSPC-2ベンチマークで1位を獲得しました。
2013：iXsystemsは、SOHO用にFreeNAS（現在はTrueNAS COREと呼ばれています）と呼ばれるZFSベースのNASデバイスを出荷し、企業向けにTrueNASを出荷します。
2014：Netgearは、企業で使用するように設計されたReadyDATAと呼ばれるZFSベースのNASデバイスのラインを出荷します。
2015：rsync.netは、顧客が独自のzpoolをプロビジョニングし、zfssendとzfsreceiveを使用してデータをインポートおよびエクスポートできるようにするクラウドストレージプラットフォームを発表しました。
2020：iXsystemsは、SOHO向けのTrueNASSCALEおよび企業向けのTrueNASと呼ばれるZFSベースのハイパーコンバージドソフトウェアの開発を開始します。

Oracle Corporation、クローズドソース、およびフォーク（2010年から）
2010年1月、OracleCorporationはSunMicrosystemsを買収し、OpenSolarisディストリビューションとオープンソース開発モデルをすぐに廃止しました。 2010年8月、OracleはSolaris OS / Networkingリポジトリのソースコードへのパブリックアップデートの提供を中止し、Solaris11を事実上クローズドソースのプロプライエタリオペレーティングシステムに戻しました。
SolarisとOpenSolarisの状況の変化に対応して、illumosプロジェクトは2010年8月3日木曜日にウェビナーを介して開始されました。これは、Solarisのオープンソースバージョンの開発を継続し、完了するための一部のコアSolarisエンジニアのコミュニティの取り組みです。 Sunがまだオープンソース化していない部品のオープンソース。 illumosは、501（c）6業界団体としてカリフォルニア州に設立された財団、illumosFoundationとして設立されました。当初の計画では、illumosはディストリビューションやフォークではないと明示的に述べられていました。ただし、OracleがOpenSolarisの廃止を発表した後、Solaris ONの最終バージョンをフォークする計画が立てられ、illumosを独自のオペレーティングシステムに進化させることができました。したがって、OpenSolarisの一部として、オープンソースバージョンのZFSはillumosに不可欠でした。
ZFSは、Solarisだけでなく、多くのプラットフォームで広く使用されていました。そのため、2013年に、オープンソースバージョンのZFSに関する開発作業の調整が、包括的なプロジェクトであるOpenZFSに渡されました。OpenZFSフレームワークを使用すると、関係者は、ZFSが機能し、独自のシステム内で統合するために必要な特定の追加コードを個別に維持しながら、コアZFSコードベースを共通に共同開発できます。

バージョン履歴
後の履歴については、OracleZFS§バージョン履歴および
OpenZFS§バージョン履歴を参照してください伝説：
古いリリース
最新のFOSS安定版リリース
ZFSファイルシステムのバージョン番号発売日重要な変更
1 OpenSolaris Nevada ビルド36
最初のリリース
2 OpenSolaris Nevada b69 強化されたディレクトリエントリ。特に、ディレクトリエントリにオブジェクトタイプが格納されるようになりました。たとえば、オブジェクト番号に加えて、ファイル、ディレクトリ、名前付きパイプなどです。
3 OpenSolaris Nevada b77 SMBを介したZFSファイルシステムの共有のサポート。大文字と小文字を区別しないサポート。システム属性のサポート。統合されたアンチウイルスサポート。
4 OpenSolaris Nevada b114 プロパティ：userquota、groupquota、userused、groupused
5 OpenSolaris Nevada b137 システム属性; シンボリックリンクは独自のオブジェクトタイプになりました
ZFSプールのバージョン番号発売日重要な変更
1 OpenSolarisネバダ b36
最初のリリース
2 OpenSolaris Nevada b38 同上ブロック
3 OpenSolaris Nevada b42 ホットスペア、ダブルパリティRAID-Z（raidz2）、改善されたRAID-Zアカウンティング
4 OpenSolaris Nevada b62 zpoolの歴史
5 OpenSolaris Nevada b62 ZFSデータセットのgzip圧縮
6 OpenSolaris Nevada b62 「bootfs」プールプロパティ
7 OpenSolaris Nevada b68 ZIL：個別のインテントログデバイスを指定する機能を追加します
8 OpenSolaris Nevada b69 zfs（1M）管理タスクを通常のユーザーに委任する機能
9 OpenSolaris Nevada b77 CIFSサーバーのサポート、データセットの割り当て
10 OpenSolaris Nevada b77 デバイスは「キャッシュデバイス」としてストレージプールに追加できます
11 OpenSolaris Nevada b94 zpoolスクラブ/リシルバーのパフォーマンスの向上
12 OpenSolaris Nevada b96 スナップショットのプロパティ
13 OpenSolaris Nevada b98 プロパティ：usedbysnapshots、usedbychildren、usedbyrefreservation、usedbydataset
14 OpenSolaris Nevada b103 passthrough-xaclinheritプロパティのサポート
15 OpenSolaris Nevada b114 プロパティ：userquota、groupquota、usuerused、groupused; FSv4も必要
16 OpenSolaris Nevada b116 STMFプロパティのサポート
17 OpenSolaris Nevada b120 トリプルパリティRAID-Z
18 OpenSolaris Nevada b121 ZFSスナップショットが保持されます
19 OpenSolaris Nevada b125 ZFSログデバイスの削除
20 OpenSolaris Nevada b128 同時にリリースされたZFSプールバージョン21のZFS重複排除プロパティをサポートするために必要なzle圧縮アルゴリズム
21 OpenSolaris Nevada b128 重複排除
22 OpenSolaris Nevada b128 zfsはプロパティを受け取ります
23 OpenSolaris Nevada b135 スリムZIL
24 OpenSolaris Nevada b137 システム属性。シンボリックリンクは、独自のオブジェクトタイプになりました。FSv5も必要です。
25 OpenSolaris Nevada b140 プールのスクラビングと再シルバー化の統計の改善
26 OpenSolaris Nevada b141 スナップショット削除のパフォーマンスの向上
27 OpenSolaris Nevada b145 スナップショット作成のパフォーマンスの向上（特に再帰的なスナップショット）
28 OpenSolaris Nevada b147 複数の仮想デバイスの交換
注：2005年のSolaris 10のリリース以降にSunが開発中のSolarisバージョンは、コード名が「Nevada」であり、OpenSolarisコードベースから派生したものです。「SolarisNevada」は、最終的にSolaris10を継承する次世代のSolarisOSのコードネームであり、この新しいコードは、新しいOpenSolarisの「Nevada」スナップショットビルドに連続して取り込まれました。 OpenSolarisは現在廃止されており、OpenIndiana はそこから分岐しています。 OpenSolarisの最終ビルド（b134）は、Solaris 11 ExpressへのアップグレードパスとしてOracle（2010-Nov-12）によって公開されました。

ZFSをサポートするオペレーティングシステムのリスト
ZFSをサポートするオペレーティングシステム、ディストリビューション、アドオン、サポートするzpoolバージョン、およびそれらが基づいているSolarisビルド（存在する場合）のリスト：
OS Zpoolバージョン Sun / Oracleビルド＃コメント
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 テストのみのライセンス
OpenSolaris 2009.06 14 b111b OpenSolaris（最後の開発） 22 b134 OpenIndiana 5000 b147 illumosに基づく分布; ビルドコード「b151a」に名前を付ける名前の衝突を作成します
Nexenta Core 3.0.1
26 b134 + GNUユーザーランド
NexentaStorコミュニティ3.0.1
26 b134 + 最大18TB、Web管理者
NexentaStorコミュニティ3.1.0
28 b134 + GNUユーザーランド
NexentaStorコミュニティ4.0
5000 b134 + 最大18TB、Web管理者
NexentaStor Enterprise 28 b134 + 無料ではない、ウェブ管理者
GNU / kFreeBSD “Squeeze”（サポートされていません） 14 パッケージ「zfsutils」が必要です
GNU / kFreeBSD “Wheezy-9″（サポートされていません） 28 パッケージ「zfsutils」が必要です FreeBSD 5000 zfs-fuse 0.7.2 23
パフォーマンスの問題に悩まされていました。廃止
Linux0.6.5.8上のZFS 5000
0.6.0リリース候補にはPOSIXレイヤーがあります
Linux上のKQInfotechのZFS 28
廃止; LinuxでLLNLがサポートするZFSに統合されたコード
BeleniX 0.8b1
14 b111 小型のライブCD配布。かつてはOpenSolarisに基づいていました
Schillix 0.7.2
28 b147 小型のライブCD配布。OpenSolarisに基づくSchilliX-ON0.8.0として
StormOS「あられ」
Nexentaコアを搭載して一度配布2.0+、DebianのLinuxの。取って代わらダイソンOS
ジャリス
ジャは、ソラpanese RIS分布を。かつてはOpenSolarisに基づいていました
MilaX 0.5 20 b128a 小型のライブCD配布。かつてはOpenSolarisに基づいていました
FreeNAS 8.0.2 / 8.2 15 FreeNAS 8.3.0 28 FreeBSD8.3に基づく
FreeNAS 9.1.0+ 5000 FreeBSD9.1以降に基づく
XigmaNAS 11.4.0.4/12.2.0.4 5000 FreeBSD 11.4 /12.2に基づく
コロナ4.5.0 22 b134 KDE
EON NAS（v0.6） 22 b130 組み込みNAS
EON NAS（v1.0beta） 28 b151a 組み込みNAS
napp-it 28/5000 Illumos / Solaris ストレージアプライアンス; OpenIndiana（Hipster）、OmniOS、Solaris 11、Linux（ZFS管理）
OmniOS CE 28/5000 illumos-OmniOSブランチ Illumosに基づく最小限の安定した/ LTSストレージサーバーの配布、コミュニティ主導
SmartOS 28/5000 Illumos b151 + Illumos（USB / CDブート）に基づく最小限のライブ配信。クラウドとハイパーバイザーの使用（KVM）
macOS 10.5、10.6、10.7、10.8、10.9 5000 MacZFS経由。OSX上のOpenZFSに取って代わられました
macOS 10.6、10.7、10.8 28 ZEVO経由; OSX上のOpenZFSに取って代わられましたNetBSD 22 MidnightBSD 6
Proxmox VE 5000
2014年以降のネイティブサポート、pve.proxmox.com / wiki / ZFS_on_Linux
Ubuntu Linux 16.04 LTS + 5000 インストール可能なバイナリモジュール、wiki.ubuntu.com / ZFSによるネイティブサポート
ZFSGuru 10.1.100
5000

も参照してください
ファイルシステムの比較
ファイルシステムのリスト
バージョニングファイルシステム–バージョニングファイルシステムのリスト

ノート
^ RAID 7は標準のRAIDレベルではありませんが、3パリティを超えるRAID構成の総称として提案されています。

参考文献
^ 「OracleSolaris11.4が一般提供のためにリリースされました」。2018年8月28日。2018年8月29日のオリジナルからアーカイブ。
^ 「リリースzfs-2.0.5」。
^ 「1.1ライセンスの問題はどうですか？」。2010年9月26日にオリジナルからアーカイブされました。
^ 「OpenZFSプロジェクトが起動します」。LWN.net。2013年9月17日。2013年10月4日のオリジナルからアーカイブ。
^ 「OpenZFSアナウンス」。OpenZFS。2013年9月17日。2018年4月2日のオリジナルからアーカイブ。
^ open-zfs.org /歴史アーカイブで2013年12月24日、ウェイバックマシン「OpenZFSはZFSプロジェクト（日付2010）フォークの効果に真のオープンソースの後継者です」
^ ショーンマイケルカーナー（2013年9月18日）。「LinuxCon：OpenZFSはオープンソースストレージを前進させる」。infostor.com。2014年3月14日にオリジナルからアーカイブされました。
^ 「OpenZFSプロジェクトが起動します」。LWN.net。2013年9月17日。2016年10月11日のオリジナルからアーカイブ。
^ 「OpenZFS–ZFSコードと機能で協力しているコミュニティ」。freebsdnews.net。2013年9月23日。2013年10月14日のオリジナルからアーカイブ。
^ “19.4。zfs管理”。www.freebsd.org。2017年2月23日にオリジナルからアーカイブされました。
^ サルス、ピーター（1994）。Unixの四半世紀。アディソン-ウェスリー。pp。199–200。ISBN
0-201-54777-5。
^ 「SunOSとSolarisとは何ですか？」。ナレッジベース。インディアナ大学テクノロジーサービス。2013年5月20日。
^ ブラウン、デビッド。「ジェフボンウィックとビルムーアとの会話」。ACMキュー。コンピューティングマシナリー協会。2011年7月16日にオリジナルからアーカイブされました。
^ 「ZFS：ファイルシステムの最後の単語」。サンマイクロシステムズ。2004年9月14日。2006年4月28日のオリジナルからアーカイブ。
^ Matthew Ahrens（2011年11月1日）。「ZFS10周年」。2016年6月28日にオリジナルからアーカイブされました。
^ Bonwick、Jeff（2005年10月31日）。「ZFS：ファイルシステムの最後の言葉」。blogs.oracle.com。2013年6月19日にオリジナルからアーカイブされました。
^ 「SunはOpenSolarisの成功した1周年を祝う」。サンマイクロシステムズ。2006年6月20日。2008年9月28日のオリジナルからアーカイブ。
^ マイケルシンガー（2005年1月25日）。「SunCracksOpenSolaris」。InternetNews.com 。
^ 「OpenSolaris.orgのZFSFAQ」。サンマイクロシステムズ。2011年5月15日にオリジナルからアーカイブされました。私たちが気に入った最大のSIプレフィックスは「zetta」でした（「yotta」は問題外でした）
^ ジェフボンウィック（2006年5月3日）。「あなたはゼータと言います、私はゼッタと言います」。ジェフボンウィックのブログ。2017年2月23日にオリジナルからアーカイブされました。そこで、私たちはついに名前をZFSに戻すことにしました。これは何の意味もありません。
^ 「OracleとNetAppはZFS訴訟を却下します」。theregister.co.uk。2010年9月9日。2017年9月9日のオリジナルからアーカイブ。
^ 拡張ファイルシステム（Ext）には、UFSからコピーされたメタデータ構造が「レミーカード（インタビュー、1998年4月）」。4月の協会。1999年4月19日。2012年2月4日のオリジナルからアーカイブ。（フランス語で）
^ Vijayan Prabhakaran（2006）。「IRONFILESYSTEMS」（PDF）。コンピュータサイエンスの哲学博士。ウィスコンシン大学マディソン校。2011年4月29日のオリジナルからアーカイブ（PDF）。
^ 「パリティが失われ、パリティが回復した」。2010年6月15日にオリジナルからアーカイブされました。
^ 「ストレージスタックのデータ破壊の分析」（PDF）。2010年6月15日のオリジナルからアーカイブ（PDF）。
^ 「オープンソースDBMSに対するディスク破損の影響」（PDF）。2010年6月15日のオリジナルからアーカイブ（PDF）。
^ Kadav、Asim; Rajimwale、Abhishek。「ZFSの信頼性分析」（PDF）。2013年9月21日のオリジナルからアーカイブ（PDF）。
^ Yupu Zhang; Abhishek Rajimwale; Andrea C. Arpaci-Dusseau; Remzi H.Arpaci-Dusseau。「ファイルシステムのエンドツーエンドのデータ整合性：ZFSケーススタディ」（PDF）。マディソン：ウィスコンシン大学コンピュータサイエンス学部。NS。14. 2011年6月26日のオリジナルからアーカイブ（PDF）。
^ ララベル、マイケル。「FreeBSDでのZFSとUFSのベンチマークとLinuxでのEXT4とBtrfsのベンチマーク」。PhoronixMedia2012 。 2016年11月29日のオリジナルからアーカイブ。
^ ララベル、マイケル。「DragonFlyBSDのHAMMERはBtrfs、ZFSと競合できますか？」。PhoronixMedia2012 。 2016年11月29日のオリジナルからアーカイブ。
^ Bonwick、Jeff（2005年12月8日）。「ZFSエンドツーエンドのデータ整合性」。blogs.oracle.com。2012年4月3日にオリジナルからアーカイブされました。
^ クック、ティム（2009年11月16日）。「ZFS自己修復のデモンストレーション」。blogs.oracle.com。2011年8月12日にオリジナルからアーカイブされました。
^ 牧場、リチャード（2007年5月4日）。「ZFS、コピー、およびデータ保護」。blogs.oracle.com。2016年8月18日にオリジナルからアーカイブされました。
^ 「涙のないZFS：ECCメモリなしのZFSの使用」。www.csparks.com。2015年12月。2021年1月13日のオリジナルからアーカイブ。
^ wdc.custhelp.com。「デスクトップ版とRAID（エンタープライズ）版のドライブの違い」。2015年1月5日にオリジナルからアーカイブされました。
^ Bonwick、Jeff（2005年11月17日）。「RAID-Z」。ジェフボンウィックのブログ。Oracleブログ。2014年12月16日にオリジナルからアーカイブされました。
^ Leventhal、Adam（2009年12月17日）。「トリプルパリティRAID以降」。キュー。7（11）：30 DOI：10.1145 / 1661785.1670144。2019年3月15日にオリジナルからアーカイブされました。
^ 「ZFSRaidzのパフォーマンス、容量、および整合性」。calomel.org。2017年11月27日にオリジナルからアーカイブされました。
^ 「RAID6が2019年に機能しなくなる理由」。ZDNet。2010年2月22日。2014年10月31日のオリジナルからアーカイブ。
^ 「ZFSに相当するfsckユーティリティは存在しません。このユーティリティは、従来、ファイルシステムの修復とファイルシステムの検証という2つの目的を果たしてきました。」「ZFSファイルシステムの整合性のチェック」。オラクル。2013年1月31日にオリジナルからアーカイブされました。
^ 「ZFSスクラブ」。freenas.org。2012年11月27日にオリジナルからアーカイブされました。
^ 「また、デバイスを交換する前、またはプールの冗長性を一時的に減らして、すべてのデバイスが現在動作していることを確認する前に、スクラブを実行する必要が」「ZFSベストプラクティスガイド」。solarisinternals.com。2015年9月5日にオリジナルからアーカイブされました。
^ ジェフボンウィック。「128ビットストレージ：あなたは高いですか？」。oracle.com。2015年5月29日にオリジナルからアーカイブされました。
^ 「ZFS：海を沸騰させ、月を消費する（Dave Brillhartのブログ）」。2015年12月8日にオリジナルからアーカイブされました。
^ 「SolarisZFS管理ガイド」。オラクル株式会社。2021年1月13日にオリジナルからアーカイブされました。
^ 「ZFSファイルシステムの暗号化」。2011年6月23日にオリジナルからアーカイブされました。
^ 「セキュリティで保護されたケーキを持ってクローンを作成する（別名暗号化+ ZFSによる重複排除）」。2013年5月29日にオリジナルからアーカイブされました。
^ 「ZFS– DebianWiki」。wiki.debian.org。2019年9月8日にオリジナルからアーカイブされました。
^ 「SolarisZFSはハイブリッドストレージプールを可能にします—経済的およびパフォーマンスの障壁を打ち破ります」（PDF）。Sun.com。2010年9月7日。2011年10月17日のオリジナルからアーカイブ（PDF）。
^ グレッグ、ブレンダン。「ZFSL2ARC」。ブレンダンのブログ。Dtrace.org。2011年11月6日にオリジナルからアーカイブされました。
^ グレッグ、ブレンダン（2009年10月8日）。「ハイブリッドストレージプール：最高速度」。ブレンダンのブログ。Dtrace.org。2016年4月5日にオリジナルからアーカイブされました。
^ 「SolarisZFSパフォーマンスチューニング：同期書き込みとZIL」。Constantin.glez.de。2010年7月20日。2012年6月23日のオリジナルからアーカイブ。
^ “リリースzfs-0.8.0″。GitHub。OpenZFS。2019年5月23日。
^ 「ZFSオンディスク仕様」（PDF）。Sun Microsystems、Inc.2006。2008年12月30日のオリジナル（PDF）からアーカイブ。
セクション2.4を参照して
^ Eric Sproul（2009年5月21日）。「ZFSナットとボルト」。slideshare.net。pp。30–31。2014年6月22日にオリジナルからアーカイブされました。
^ 「ZFS重複排除」。blogs.oracle.com。2019年12月24日にオリジナルからアーカイブされました。
^ Gary Sims（2012年1月4日）。「FreeNAS8を使用したZFSベースのネットワーク接続ストレージの構築」。TrainSignalトレーニング。TrainSignal、Inc。2012年5月7日にオリジナル（ブログ）からアーカイブされました。
^ レイヴァンドルソン。「要約：重複排除メモリ要件」。zfs-メーリングリストについて話し合います。2012年4月25日にオリジナルからアーカイブされました。
^ 「ZFSTuningGuide」。2012年1月16日にオリジナルからアーカイブされました。
^ クリスメラー（2012年10月12日）。「GreenBytesは全脂肪クローンVDIパンパーを振り回します」。レジスター。2013年3月24日にオリジナルからアーカイブされました。
^ クリスメラー（2012年6月1日）。「新参者は箱から出して、すべての来訪者に安く販売する予定です」。レジスター。2013年8月12日にオリジナルからアーカイブされました。
^ クリスメラー（2014年12月11日）。「重複排除、重複排除…重複排除、重複排除、重複排除：OracleはZFSダイヤモンドを研磨します」。レジスター。2017年7月7日にオリジナルからアーカイブされました。
^ 「チェックサムとZFSでのそれらの使用」。github.com。2018年9月2日。2019年7月19日のオリジナルからアーカイブ。
^ 「SolarisZFS管理ガイド」。第6章ZFSファイルシステムの管理。2011年2月5日にオリジナルからアーカイブされました。
^ 「スモーキンミラー」。blogs.oracle.com。2006年5月2日。2011年12月16日のオリジナルからアーカイブ。
^ 「ZFSブロック割り当て」。ジェフボンウィックのウェブログ。2006年11月4日。2012年11月2日のオリジナルからアーカイブ。
^ 「同上ブロック—驚くべきテープ忌避剤」。フリッピンオフビットウェブログ。2006年5月12日。2013年5月26日のオリジナルからアーカイブ。
^ 「新しいディスクの追加と同上ブロックの動作」。2011年8月23日にオリジナルからアーカイブされました。
^ 「OpenSolaris.org」。サンマイクロシステムズ。2009年5月8日にオリジナルからアーカイブされました。
^ 「Solaris11Express 2010.11の新機能」（PDF）。オラクル。2010年11月16日のオリジナルからアーカイブ（PDF）。
^ 「10。共有—FreeNASユーザーガイド9.3目次」。doc.freenas.org。2017年1月7日にオリジナルからアーカイブされました。
^ Zhang、Yupu; Rajimwale、Abhishek; Arpaci-Dusseau、Andrea C。; Arpaci-Dusseau、Remzi H.（2018年1月2日）。「ファイルシステムのエンドツーエンドのデータ整合性：ZFSケーススタディ」。USENIXアソシエーション。NS。3. 2021年1月13日にオリジナルからアーカイブされました。2020年6月7日–ACMデジタルライブラリ経由で取得。
^ 「Arsウォークスルー：LinuxでのZFS次世代ファイルシステムの使用」。arstechnica.com。2017年2月10日にオリジナルからアーカイブされました。
^ 「バグID4852783：プール容量を減らしてください」。OpenSolarisプロジェクト。2009年6月29日にオリジナルからアーカイブされました。
^ ゲッベルス、マリオ（2007年4月19日）。「プールからvdevを完全に削除する」。zfs-discuss（メーリングリスト）。
アーカイブリンク2021年1月13日、ウェイバックマシンでアーカイブ
^ クリスSiebenmann将来のVDEVの除去に関する情報アーカイブで2016年8月11日、ウェイバックマシン、大学トロント、ブログ、引用：アレックス・リースによる非公式Twitterの発表アーカイブ2016年8月11日、でウェイバックマシン
^ 「データ管理機能–Oracle®Solaris11.4の新機能」。2019年9月24日にオリジナルからアーカイブされました。
^ 「Expand-O-MaticRAIDZ」。アダムレヴェンタール。2008年4月7日。2011年12月28日のオリジナルからアーカイブ。
^ “zpool（1M）”。Download.oracle.com。2010年6月11日。2021年1月13日のオリジナルからアーカイブ。
^ ブレンダン（2008年12月2日）。「25万NFSIOPS」。OracleSun。2011年12月17日にオリジナルからアーカイブされました。
^ レベンサル、アダム。「トリプルパリティRAIDZ」。AdamLeventhalのブログ。2011年4月16日にオリジナルからアーカイブされました。
^ 「過給ZFSデータ復旧」。2018年11月29日にオリジナルからアーカイブされました。
^ 「ZFSおよびOpenZFS」。iXSystems 。
^ 「Sunは独自のストレージアプライアンスを展開しています」。techworld.com.au。2008年11月11日。2013年11月13日のオリジナルからアーカイブ。
^ クリスメラー（2013年10月2日）。「オラクルは、巨大なZFSファイラーでベンチマークの頂点に立つ」。theregister.co.uk。2017年7月7日にオリジナルからアーカイブされました。
^ 「iXsystemによってシリコンバレーに構築された統合ZFSストレージアプライアンス」。ixsystems.com。2014年7月3日にオリジナルからアーカイブされました。
^ 「TrueNAS12とTrueNASスケールが正式にここにあります！」。ixsystems.com 。
^ 「ReadyDATA516–統合ネットワークストレージ」（PDF）。netgear.com。2014年7月15日のオリジナルからアーカイブ（PDF）。
^ ジムソルター（2015年12月17日）。「rsync.net：クラウドへのZFSレプリケーションがついに登場しました—そしてそれは高速です」。arstechnica.com。2017年8月22日にオリジナルからアーカイブされました。
^ rsync.net、Inc。「SSHを介したZFS送受信のクラウドストレージ」。rsync.net。2017年7月21日にオリジナルからアーカイブされました。
^ スティーブンスタリオン/オラクル（2010年8月13日）。「SXCEのアップデート」。偶像破壊の傾向。
^ AlasdairLumsden。「OpenSolarisはキャンセルされました。Solaris11Expressに置き換えられます」。osol-discuss（メーリングリスト）。2010年8月16日にオリジナルからアーカイブされました。
^ Solarisのまだみかん開いたが、OpenSolarisのディストリビューションは、死んでいるアーカイブで2017年9月5日、ウェイバックマシン上アルステクニカライアン・ポール（2010年8月16日）で
^ ギャレットダモール（2010年8月3日）。「Illumos-新たな希望と光の泉-ギャレット・ダモールによる発表」（PDF）。illumos.org 。
^ 「OpenSolarisはどこにありますか？Illumosがマントルを取り上げます」。2015年9月26日にオリジナルからアーカイブされました。
^ ギャレットダモール（2010年8月13日）。「手は強制されるかもしれない」。
^ “Sun Microsystemsの管理下にある間、Solaris Nevada（Solaris10を最終的に引き継ぐ次世代のSolarisOSのコードネーム）のスナップショットが隔週であり、この新しいコードは利用可能な新しいOpenSolarisプレビュースナップショットに取り込まれました。 Genunix.orgで。OpenSolarisのの安定したリリースはのオフに基づいているこれらのネバダ州は、構築します。」ララベル、マイケル。「OracleはOpenSolarisの背後に立つようです」。マイケル・ララベルメディア。2016年11月29日にオリジナルからアーカイブされました。
^ Ljubuncic、Igor（2011年5月23日）。「OpenIndiana—まだ希望があります」。DistroWatch。2012年10月27日にオリジナルからアーカイブされました。
^ 「ProjectOpenIndianaへようこそ！」。プロジェクトOpenIndiana。2010年9月10日。2012年11月27日のオリジナルからアーカイブ。

参考文献
渡辺スコット（2009年11月23日）。Solaris ZFS Essentials（第1版）。プレンティスホール。NS。256. ISBN 978-0-13-700010-4。2012年10月1日にオリジナルからアーカイブされました。

外部リンク
フォークうん！illumosの台頭と発展-Solarisの歴史の多く、Sunによるオープンソースの決定、ZFSの作成、およびOracleの買収後にクローズドソースとフォークを引き起こしたイベントをカバーするスライドショー。
最高のクラウドファイルシステムは、クラウドが存在する前に作成されました（2018年12月15日にアーカイブされました）
SVMミラーリングとZFSミラーリングの比較
EON ZFSストレージ（NAS）ディストリビューション
ファイルシステムのエンドツーエンドのデータ整合性：ZFSケーススタディ
ZFS – Zettabyteファイルシステム（2013年2月28日にアーカイブ）
ZFSとRAID-Z：Über-FS？
ZFS：ファイルシステムの最後の言葉、JeffBonwickとBillMoore（2017年8月29日にアーカイブ）
ZFSインテントログ（ZIL）の視覚化、 2013年4月、Aaron Toponce
OpenZFSを含む
illumosの機能
より多くのリンクがある以前のwikiページ：Getting Started with ZFS、2014年9月15日（2018年12月30日にアーカイブ）、illumosドキュメントの一部