ZFS

ZFS
開発者当初はSun Microsystems、 2010年からはOracle Corporation、2013年からはOpenZFS
変種Oracle ZFS、OpenZFS
紹介された2005年11月; OpenSolarisの20年前 (2005-11)
構造
ディレクトリの内容拡張可能なハッシュ
制限
最大ボリュームサイズ256兆 ヨビバイト（2の128 乗バイト）[1]
最大ファイルサイズ16 エクスビバイト（2 64 バイト）
最大ファイル数
  • ディレクトリあたり: 2 48
  • ファイルシステムごと: 無制限[1]
ファイル名の最大長1023 ASCII文字（ Unicodeなどのマルチバイト文字規格では文字数が少なくなります）
特徴
フォークはい（「拡張属性」と呼ばれますが、本格的なストリームです）
属性POSIX、拡張属性
ファイルシステムの
権限		Unix パーミッション、NFSv4 ACL
透過的な
圧縮		はい
透過的な
暗号化		はい
データ重複排除はい
コピーオンライトはい
他の
サポートされている
オペレーティングシステム

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

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

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

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

歴史

2004–2010: サン・マイクロシステムズでの開発

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に移植されました。

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

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

2010年～現在: Oracleでの開発、OpenZFS

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]後継として見ることができます。

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

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

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

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

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

レイド

ZFSがデータの整合性を保証するには、データまたはパリティ情報の複数のコピーが必要であり、通常は複数のディスクに分散されます。これは通常、RAIDコントローラまたはいわゆる「ソフト」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-Zとミラーリング

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には組み込みのscrub関数があり、定期的にすべてのデータを検査し、サイレント破損などの問題を修復します。いくつかの違いは次のとおりです。

  • fsck はオフラインのファイルシステムで実行する必要があります。つまり、ファイルシステムはアンマウントする必要があり、修復中は使用できません。一方、scrub はマウントされたライブ ファイルシステムで使用するように設計されているため、ZFS ファイルシステムをオフラインにする必要はありません。
  • fsckは通常、メタデータ（ジャーナルログなど）のみをチェックし、データ自体をチェックすることはありません。つまり、fsckを実行した後でも、データが元の保存データと一致しない可能性があります。
  • チェックサムがデータと共に保存されている場合（多くのファイルシステムでよくあるケース）、fsck は必ずしもデータを検証して修復できるとは限りません。これは、チェックサムが破損していたり​​、読み取り不能になっている可能性があるためです。ZFS は常にチェックサムを検証対象のデータとは別に保存するため、信頼性が向上し、scrub によるボリュームの修復能力も向上します。また、ZFS はデータの複数のコピーを保存します。特にメタデータは、ディスクごとに複数のコピー、ボリュームごとに複数のディスクミラーを持つため、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の19倍ものデータを処理できます。ZFSの上限は非常に大きく設計されているため、実際には上限に達することはありません。例えば、1つのzpoolに2128ビットのデータを完全に格納するには、3×10の24TBのハードディスクドライブが必要になります。  [ 45]

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

  • 16エクスビバイト（2 64バイト）: 1つのファイルの最大サイズ
  • 2 48 : 個々のディレクトリ内のエントリ数[46]
  • 16エクスビバイト: 属性の最大サイズ
  • 2 56 : ファイルの属性の数（実際にはディレクトリ内のファイル数は2 48に制限されます）
  • 256京ゼビバイト（2 128バイト）: zpoolの最大サイズ
  • 2 64 : 任意の zpool 内のデバイスの数
  • 2 64 : zpool内のファイルシステムの数
  • 2 64 : システム内のzpoolの数

暗号化

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

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

ZFSネイティブ暗号化の使用時に障害が発生したというエンドユーザーからの報告が散見されますが、正確な原因は解明されていません。[50] [51]

読み取り/書き込み効率

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

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

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

その他の機能

ストレージデバイス、スペア、およびクォータ

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

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

すべての仮想デバイス（vdev）のストレージ容量は、zpool 内のすべてのファイルシステムインスタンスで利用できます。クォータを設定することで、ファイルシステムインスタンスが占有できる容量を制限できます。また、予約を設定することで、ファイルシステムインスタンスが確実に使用できる容量を確保できます。

キャッシュメカニズム: ARC、L2ARC、トランザクショングループ、ZIL、SLOG、特殊VDEV

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

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

 保管場所読み取りキャッシュ書き込みキャッシュ
1次キャッシュRAM内ARC（ Adaptive Replacement Cache ）アルゴリズムの一種を使用しているため、ARCと呼ばれます。RAMは常にキャッシュに使用されるため、このレベルは常に存在します。ARCアルゴリズムの効率性により、ARCサイズが十分に大きい場合、ディスクにアクセスする必要はほとんどありません。RAMが小さすぎる場合、ARCはほとんど機能しません。この場合、ZFSは常に基盤となるディスクにアクセスする必要があり、パフォーマンスに大きな影響を与えます。「トランザクショングループ」によって処理されます。書き込みは短時間（通常5～30秒）で、指定された制限まで照合され、各グループがディスクに書き込まれるのと同時に、理想的には次のグループの照合が行われます。これにより、基盤となるディスクへの書き込みをより効率的に整理できますが、電源喪失やハードウェア障害が発生した場合、最新のトランザクションのデータがわずかに失われるリスクがあります。実際には、電源喪失のリスクはZFS書き込みジャーナリングとSLOG/ZIL第2層書き込みキャッシュプール（後述）によって回避されるため、書き込みが失われるのは、書き込み障害が第2層SLOGプールの完全な損失と同時に発生した場合のみであり、しかも同期書き込みとSLOGの使用に関する設定が、そのような状況が発生するように設定されている場合にのみ発生します。データの受信速度が書き込み速度よりも速い場合、ディスクが追いつくまでデータの受信は一時停止されます。
2次キャッシュとインテントログ高速ストレージデバイス（現在のバージョンの ZFS では中断なく「ライブ」システムに追加したり削除したりできますが、古いバージョンでは必ずしもそうとは限りません）L2ARC （「Level 2 ARC」）と呼ばれるオプション機能。ZFSは可能な限り多くのデータをL2ARCにキャッシュします。L2ARCは、重複排除テーブル全体をL2ARCにキャッシュできる場合、重複排除処理を大幅に高速化します。L2ARCを空の状態から完全にキャッシュするには（ZFSがどのデータが「ホット」でキャッシュすべきかを判断するまで）、数時間かかる場合があります。L2ARCデバイスが失われた場合、すべての読み取りはディスクに送信されるためパフォーマンスが低下しますが、それ以外は何も起こりません（データが失われることはありません）。SLOGまたはZIL （ZFSインテントログ）と呼ばれるこれらの用語は、しばしば誤って使用されています。SLOG（セカンダリログデバイス）は、システム問題発生時に書き込みを記録するための、別デバイス上のオプションの専用キャッシュです。SLOGデバイスが存在する場合、それはZFSインテントログのセカンドレベルログとして使用され、別個のキャッシュデバイスが提供されていない場合は、代わりにメインストレージデバイス上にZILが作成されます。したがって、SLOGは技術的には、プールの高速化のためにZILがオフロードされる専用ディスクを指します。厳密に言えば、ZFSはディスク書き込みをキャッシュするためにSLOGデバイスを使用するわけではありません。むしろ、SLOGは書き込みが可能な限り迅速に永続的なストレージメディアにキャプチャされるようにするために使用します。そのため、電源喪失や書き込み障害が発生した場合でも、書き込みとして認識されたデータは失われません。SLOGデバイスにより、ZFSはHDDなどのはるかに低速なストレージデバイスであっても、書き込みを迅速に保存し、書き込み済みとして迅速に報告することができます。通常の動作では、SLOG は参照も読み取りも行われず、キャッシュとしても機能しません。SLOG の目的は、最終的な書き込みが失敗した場合に備えて、照合と「書き出し」にかかる数秒間、転送中のデータを保護することです。すべてが順調に進んだ場合、ストレージプールは次の 5 ～ 60 秒以内に更新され、現在のトランザクショングループがディスクに書き出されます (上記参照)。この時点で、SLOG に保存されている書き込みは無視され、上書きされます。書き込みが最終的に失敗した場合、またはシステムがクラッシュや障害に見舞われて書き込みが妨げられた場合、ZFS は SLOG を読み戻すことで (SLOG が読み出されるのはこれが唯一のタイミングです)、書き込みが確認されたすべての書き込みを特定し、これを用いてデータ損失を完全に修復できます。

これは、大量の同期書き込みが行われる場合（ESXi、NFS、一部のデータベースなど）[57]に非常に重要になります。このような場合、クライアントはアクティビティを続行する前に書き込みが成功したことを確認する必要があります。SLOGを使用すると、ZFSは、データストレージの状態に関してクライアントを誤解させるリスクなしに、毎回メインストアに書き込むよりもはるかに速く書き込みが成功したことを確認できます。SLOGデバイスがない場合、メインデータプールの一部が同じ目的で使用されますが、速度は遅くなります。

ログデバイス自体が失われた場合、最新の書き込みが失われる可能性があるため、ログデバイスはミラーリングする必要があります。以前のバージョンのZFSでは、ログデバイスの損失はzpool全体の損失につながる可能性がありましたが、現在はそうではありません。したがって、独立したログデバイスを使用する予定がある場合は、ZFSをアップグレードする必要があります。

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

特別VDEVクラス

OpenZFS 0.8以降では、ファイルシステムのメタデータ、オプションでデータ重複排除テーブル（DDT）、および小さなファイルシステムブロックを優先的に保存するようにSpecial VDEVクラスを設定できます。[58]これにより、例えば、通常のファイルデータは回転ディスクに保存し、メタデータを保存するためのSpecial VDEVを高速ソリッドステートストレージ上に作成することが可能になります。これにより、ファイルシステム全体をソリッドステートストレージに保存するコストをかけずに、ファイルシステムのトラバーサル、スクラブ、リシルバーといったメタデータを大量に使用する操作を高速化できます。

コピーオンライトトランザクションモデル

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

スナップショットとクローン

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

書き込み可能なスナップショット（「クローン」）を作成することもできます。これにより、ブロックセットを共有する2つの独立したファイルシステムが作成されます。クローンファイルシステムのいずれかに変更が加えられると、その変更を反映した新しいデータブロックが作成されますが、変更されていないブロックは、クローンの数に関係なく引き続き共有されます。これは、コピーオンライトの原理を実装したものです。

スナップショットの送受信

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

ダイナミックストライピング

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

可変ブロックサイズ

ZFSは可変サイズのブロックを使用し、デフォルトサイズは128KBです。特定のワークロードでは大きなブロックではパフォーマンスが低下しますが、管理者は利用可能な機能によって最大ブロックサイズを調整できます。データ圧縮が有効になっている場合は、可変ブロックサイズが使用されます。ブロックを圧縮してより小さなブロックサイズに収まる場合は、ディスク上でより小さなブロックサイズを使用することで、ストレージ使用量を削減し、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ソートと集約を主張した。[要出典]
  • 長さとストライドの自動検出機能を備えた複数の独立したプリフェッチ ストリーム。[引用が必要]
  • 並列かつ一定時間のディレクトリ操作。[要引用]
  • エンドツーエンドのチェックサム。一種の「データ整合性フィールド」を使用し、データ破損の検出（およびプール内に冗長性がある場合は回復）を可能にします。速度最適化（f​​letcher）、標準化とセキュリティ（ 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] OpenZFSでは、vdevの数を減らすための機能強化が開発中です。[80]冗長性のない最上位vdevを削除することによるオンライン縮小は、2018年8月にリリースされたSolaris 11.4 [81]および2019年5月にリリースされたOpenZFS (ZoL) 0.8からサポートされています。 [58]
  • 2008年時点では、RAID Z、RAID Z2、またはRAID Z3の仮想デバイスにディスクを列として追加することはできませんでした。ただし、代わりに新しいRAID Zの仮想デバイスを作成し、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月現在、OpenZFSでは、大幅に強化された一連のメソッドが段階的に導入されています。これには以下が含まれます。[86]
  • コードのリファクタリング、マウント失敗に関するより詳細な診断およびデバッグ情報により、破損したプールの問題の診断と修正が簡素化されます。
  • 保存されたプール設定を信頼または不信頼にする機能。これは特に強力で、最上位の仮想デバイスが欠落または故障している場合、あるいは最上位のデータが疑わしい場合でもプールをマウントできます。また、プール設定の変更が問題に関係している場合は、その変更を巻き戻すこともできます。破損したプールがマウントされると、安全のために読み取り可能なファイルをコピーできます。また、プール内の他の場所に保存されているコピーを使用することで、欠落した仮想デバイスであってもデータを再構築できる可能性があります。
  • あるプールに必要なディスクが誤って削除され、別のプールに追加されたために、最初のプールに関連するメタデータが失われ、読み取り不能になる状況を修正する機能。

OpenZFSとZFS

Oracle Corporationは、2010年のSun買収後、ZFSとOpenSolarisの公開開発を中止しました。一部の開発者は、OpenSolarisの最後の公開リリースをIllumosプロジェクトとしてフォークしました。ZFSには大きな利点があるため、機能やコマンドが異なる複数のプラットフォームに移植されています。開発の連携と分断を避けるため、 2013年にOpenZFSが設立されました。

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

商用およびオープンソース製品

  • 2008年：サンは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向けのTrueNAS SCALEとエンタープライズ向けのTrueNASと呼ばれるZFSベースのハイパーコンバージドソフトウェアの開発を開始しました。 [91]

Oracle Corporation、クローズドソース、フォーク（2010年から）

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 は、Illumos Foundation という財団として設立され、カリフォルニア州で501(c)6業界団体として法人化されました。当初の計画では、illumos はディストリビューションやフォークにはならないと明記されていました。しかし、Oracle が OpenSolaris の廃止を発表した後、Solaris ON の最終バージョンをフォークして、illumos を独自のオペレーティングシステムに進化させる計画が立てられました。[100]そのため、OpenSolaris の一部として、ZFS のオープンソース版は illumos にとって不可欠なものとなりました。

ZFSはSolarisをはじめ、数多くのプラットフォームで広く利用されていました。そのため、2013年には、オープンソース版ZFSの開発作業の調整が、アンブレラプロジェクトであるOpenZFSに引き継がれました。OpenZFSフレームワークにより、関係するあらゆる関係者がZFSのコアコードベースを共同で開発できるようになり、同時に、ZFSが各自のシステムで動作し統合するために必要な特定の追加コードを個別に保守することが可能になります。

バージョン履歴

伝説：
古いリリース
最新のFOSS安定リリース
ZFS ファイルシステムのバージョン番号発売日重要な変更
1OpenSolaris ネバダ[101]ビルド 36最初のリリース
2OpenSolaris ネバダ b69ディレクトリエントリの強化。特に、ディレクトリエントリにはオブジェクト番号に加えて、ファイル、ディレクトリ、名前付きパイプなどのオブジェクトタイプが保存されるようになりました。
3OpenSolaris ネバダ b77SMB経由のZFSファイルシステムの共有をサポートします。大文字と小文字を区別しません。システム属性をサポートします。統合されたウイルス対策をサポートします。
4OpenSolaris ネバダ b114プロパティ: userquota、groupquota、userused、groupused
5OpenSolaris ネバダ b137システム属性; シンボリックリンクが独自のオブジェクトタイプになりました
ZFS プールのバージョン番号発売日重要な変更
1オープンソラリスネバダ[101] b36最初のリリース
2OpenSolaris ネバダ b38ディットブロック
3OpenSolaris ネバダ b42ホットスペア、ダブルパリティ RAID-Z (raidz2)、改良された RAID-Z アカウンティング
4OpenSolaris ネバダ b62zpoolの歴史
5OpenSolaris ネバダ b62ZFSデータセットのgzip圧縮
6OpenSolaris ネバダ b62「bootfs」プールプロパティ
7OpenSolaris ネバダ b68ZIL: 個別のインテントログデバイスを指定する機能を追加
8OpenSolaris ネバダ b69zfs(1M) 管理タスクを一般ユーザーに委任する機能
9OpenSolaris ネバダ b77CIFSサーバーのサポート、データセットのクォータ
10OpenSolaris ネバダ b77デバイスは「キャッシュデバイス」としてストレージプールに追加できます
11OpenSolaris ネバダ b94zpool スクラブ / リシルバー パフォーマンスの向上
12OpenSolaris ネバダ b96スナップショットのプロパティ
13OpenSolaris ネバダ b98プロパティ: usedbysnapshots、usedbychildren、usedbyrefreservation、usedbydataset
14OpenSolaris ネバダ b103passthrough-x aclinherit プロパティのサポート
15OpenSolaris ネバダ b114プロパティ: userquota、groupquota、usuerused、groupused。FS v4 でも必須
16OpenSolaris ネバダ b116STMFプロパティのサポート
17OpenSolaris ネバダ b120トリプルパリティ RAID-Z
18OpenSolaris ネバダ b121ZFSスナップショットは
19OpenSolaris ネバダ b125ZFSログデバイスの削除
20OpenSolaris ネバダ b128同時にリリースされたZFSプールバージョン21のZFS重複排除プロパティをサポートするために必要なzle圧縮アルゴリズム
21OpenSolaris ネバダ b128重複排除
22OpenSolaris ネバダ b128zfs 受信プロパティ
23OpenSolaris ネバダ b135スリムZIL
24OpenSolaris ネバダ b137システム属性。シンボリックリンクが独自のオブジェクトタイプになりました。FS v5 も必要です。
25OpenSolaris ネバダ b140プール洗浄と再シルバー化の統計の改善
26OpenSolaris ネバダ b141スナップショット削除のパフォーマンスが向上
27OpenSolaris ネバダ b145スナップショット作成のパフォーマンスが向上しました（特に再帰スナップショット）
28OpenSolaris ネバダ b147複数の仮想デバイスの置き換え

注: 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 ビルド (存在する場合) のリスト:

OSZpoolバージョンSun/Oracle ビルド番号コメント
Oracle Solaris 11.44911.4.51 (11.4 SRU 51) [104]
Oracle Solaris 11.3370.5.11-0.175.3.1.0.5.0
Oracle Solaris 10 1/13 (U11)32
Oracle Solaris 11.2350.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.1134b175
Oracle Solaris Express 11 2010.1131b151aテストのみのライセンス
オープンソラリス2009.0614b111b
OpenSolaris (最終開発)22b134
オープンインディアナ5000b147illumosに基づくディストリビューション。ビルドコード 'b151a' という名前が衝突する
ネクセンタコア 3.0.126b134+GNUユーザーランド
NexentaStorコミュニティ 3.0.126b134+最大18 TB、Web管理
NexentaStorコミュニティ 3.1.028b134+GNUユーザーランド
NexentaStorコミュニティ 4.05000b134+最大18 TB、Web管理
ネクセンタストアエンタープライズ28b134 +無料ではありません、ウェブ管理者
GNU/kFreeBSD "Squeeze" (サポート対象外)14パッケージ「zfsutils」が必要です
GNU/kFreeBSD "Wheezy-9" (サポート対象外)28パッケージ「zfsutils」が必要です
フリーBSD5000
zfs-fuse 0.7.223パフォーマンスの問題に悩まされ、廃止された
Linux 上の ZFS 0.6.5.850000.6.0リリース候補にはPOSIXレイヤーがあります
KQ Infotech の Linux 上の ZFS28廃止。Linux上のLLNL対応ZFSに統合されたコード
ベレニクス0.8b114b111小型のライブCDディストリビューション。かつてはOpenSolarisをベースにしていた。
シリックス 0.7.228b147小型ライブCDディストリビューション。OpenSolarisベースのSchillX-ON 0.8.0として
StormOSの「雹」かつてはNexenta Core 2.0+、Debian Linuxをベースにしていたが、Dyson OSに置き換えられた。
ジャリス日本語版Sola risディストリビューション。かつてはOpenSolarisをベースにしていた。
ミラックス 0.520b128a小型のライブCDディストリビューション。かつてはOpenSolarisをベースにしていた。
フリーNAS 8.0.2 / 8.215
フリーNAS 8.3.028FreeBSD 8.3 ベース
FreeNAS 9.1.0以降5000FreeBSD 9.1以降に基づく
シグマNAS 11.4.0.4/12.2.0.45000FreeBSD 11.4/12.2 ベース
コロナ 4.5.022b134KDE
EON NAS (v0.6)22b130組み込みNAS
EON NAS (v1.0ベータ)28b151a組み込みNAS
ナップイット28/5000イルモス/ソラリスストレージアプライアンス; OpenIndiana (Hipster)、OmniOS、Solaris 11、Linux (ZFS 管理)
オムニOS CE28/5000illumos-OmniOS ブランチIllumos をベースにした、コミュニティ主導の最小限の安定/LTS ストレージサーバーディストリビューション
スマートOS28/5000イルモス b151+Illumosに基づく最小限のライブ配信(USB/CD ブート)、クラウドおよびハイパーバイザーの使用 (KVM)
macOS 10.5、10.6、10.7、10.8、10.95000MacZFS経由。OS XではOpenZFSに置き換えられた。
macOS 10.6、10.7、10.828ZEVO経由。OS XではOpenZFSに置き換えられた。
ネットBSD22
ミッドナイトBSD6
プロクスモックスVE50002014年からネイティブサポート、pve.proxmox.com/wiki/ZFS_on_Linux
Ubuntu Linux 16.04 LTS+5000インストール可能なバイナリモジュールによるネイティブサポート、wiki.ubuntu.com/ZFS
ZFSGuru 10.1.1005000

参照

注記

  1. ^ RAID 7は標準的なRAIDレベルではありませんが、3パリティ以上のRAID構成を表す包括的な用語として提案されています[38]

参考文献

  1. ^ ab 「ZFSとは？」『Oracle Solaris ZFS管理ガイド』。Oracle。2016年3月4日時点のオリジナルよりアーカイブ。 2015年12月29日閲覧。
  2. ^ 「ZFS on Linux ライセンス」GitHub . 2020年5月17日閲覧。
  3. ^ Corbet, Jonathan (2013年9月17日). 「OpenZFSプロジェクトが始動」. LWN.net . 2013年10月4日時点のオリジナルよりアーカイブ。2013年10月1日閲覧。
  4. ^ “OpenZFS 発表”. OpenZFS . 2013年9月17日. 2018年4月2日時点のオリジナルよりアーカイブ。 2013年9月19日閲覧。
  5. ^ open-zfs.org /History アーカイブ 2013年12月24日、Wayback Machine 「OpenZFSは、ZFSプロジェクトの真のオープンソースの後継です [...] フォークの影響（2010年から現在まで）
  6. ^ Sean Michael Kerner (2013年9月18日). 「LinuxCon: OpenZFS moves Open Source Storage Forward」. infostor.com. 2014年3月14日時点のオリジナルよりアーカイブ。2013年10月9日閲覧。
  7. ^ Corbet, Jonathan (2013年9月17日). 「OpenZFSプロジェクトが始動」. LWN.net . 2016年10月11日時点のオリジナルよりアーカイブ。2013年10月1日閲覧。
  8. ^ “OpenZFS—ZFSのコードと機能に協力するコミュニティ”. freebsdnews.net. 2013年9月23日. 2013年10月14日時点のオリジナルよりアーカイブ。 2014年3月14日閲覧。
  9. ^ “The Starline ZFS FAQ”. Starline . 2024年7月7日時点のオリジナルよりアーカイブ。 2024年7月20日閲覧。
  10. ^ ab “19.4. zfs 管理”. www.freebsd.org . 2017年2月23日時点のオリジナルよりアーカイブ。 2017年2月22日閲覧。
  11. ^ Salus, Peter (1994). Unixの25年. Addison-Wesley. pp.  199– 200. ISBN 0-201-54777-5。
  12. ^ 「SunOSとSolarisとは何か？」ナレッジベース。インディアナ大学テクノロジーサービス。2013年5月20日。2013年11月4日時点のオリジナルよりアーカイブ。2014年11月10日閲覧。
  13. ^ ブラウン、デイビッド。「ジェフ・ボンウィックとビル・ムーアとの対談」ACMキュー。Association for Computing Machinery。2011年7月16日時点のオリジナルよりアーカイブ。 2015年11月17日閲覧。
  14. ^ 「ZFS: ファイルシステムの最終形」Sun Microsystems. 2004年9月14日. 2006年4月28日時点のオリジナルよりアーカイブ。2006年4月30日閲覧。
  15. ^ Matthew Ahrens (2011年11月1日). “ZFS 10周年”. 2016年6月28日時点のオリジナルよりアーカイブ。2012年7月24日閲覧。
  16. ^ ab Bonwick, Jeff (2005年10月31日). 「ZFS: ファイルシステムの決定版」. blogs.oracle.com . 2013年6月19日時点のオリジナルよりアーカイブ。 2013年6月22日閲覧。
  17. ^ “Sun Celebrates Successful One-Year Anniversary of OpenSolaris”. Sun Microsystems. 2006年6月20日. 2008年9月28日時点のオリジナルよりアーカイブ。2018年4月30日閲覧。
  18. ^ Michael Singer (2005年1月25日). 「Sun Cracks Open Solaris」. InternetNews.com. 2011年6月22日時点のオリジナルよりアーカイブ。 2010年4月12日閲覧。
  19. ^ 「ZFS FAQ at OpenSolaris.org」。Sun Microsystems。2011年5月15日時点のオリジナルよりアーカイブ。 2011年5月18日閲覧。SI接頭辞の中で私たちが気に入ったのは「ゼッタ」でした（「ヨッタ」は論外でした） 。
  20. ^ Jeff Bonwick (2006年5月3日). 「You say zeta, I say zetta」. Jeff Bonwick's Blog . 2017年2月23日時点のオリジナルよりアーカイブ。 2017年4月21日閲覧。そこで最終的に、名前をZFSに戻すことにしました。ZFSは、何の略称でもありません。
  21. ^ “OracleとNetApp、ZFS訴訟を却下”. theregister.co.uk. 2010年9月9日. 2017年9月9日時点のオリジナルよりアーカイブ。2013年12月24日閲覧。
  22. ^ 拡張ファイルシステム（Ext）は、 UFSからコピーされたメタデータ構造を持っています。 「Rémy Card（インタビュー、1998年4月）」April Association、1999年4月19日。2012年2月4日時点のオリジナルよりアーカイブ。 2012年2月8日閲覧。（フランス語）
  23. ^ Vijayan Prabhakaran (2006). 「IRON FILE SYSTEMS」(PDF) .コンピュータサイエンス博士号. ウィスコンシン大学マディソン校. 2011年4月29日時点のオリジナルよりアーカイブ(PDF) . 2012年6月9日閲覧。
  24. ^ “Parity Lost and Parity Regained”. 2010年6月15日時点のオリジナルよりアーカイブ。2010年11月29日閲覧。
  25. ^ 「ストレージスタックにおけるデータ破損の分析」(PDF) 。 2010年6月15日時点のオリジナルよりアーカイブ(PDF) 。 2010年11月29日閲覧。
  26. ^ 「ディスク破損がオープンソースDBMSに与える影響」(PDF) 。 2010年6月15日時点のオリジナルよりアーカイブ(PDF) 。 2010年11月29日閲覧。
  27. ^ Kadav, Asim; Rajimwale, Abhishek. 「ZFSの信頼性分析」(PDF) 。 2013年9月21日時点のオリジナルよりアーカイブ(PDF) 。 2013年9月19日閲覧。
  28. ^ Yupu Zhang、Abhishek Rajimwale、Andrea Arpaci-Dusseau、Remzi H. Arpaci-Dusseau (2010). 「ファイルシステムのエンドツーエンドのデータ整合性：ZFSのケーススタディ」（PDF） . USENIX Conference on File and Storage Technologies . CiteSeerX 10.1.1.154.3979 . S2CID  5722163. Wikidata  Q111972797 . 2010年12月6日閲覧。 
  29. ^ Larabel, Michael. 「FreeBSD上のZFSとUFS、Linux上のEXT4とBtrfsのベンチマーク」Phoronix Media 2012. 2016年11月29日時点のオリジナルよりアーカイブ。 2012年11月21日閲覧。
  30. ^ Larabel, Michael. 「DragonFlyBSDのHAMMERはBtrfsやZFSに匹敵するか？」Phoronix Media 2012年。2016年11月29日時点のオリジナルよりアーカイブ。2012年11月21日閲覧。
  31. ^ abc Bonwick, Jeff (2005年12月8日). 「ZFS エンドツーエンドのデータ整合性」. blogs.oracle.com . 2012年4月3日時点のオリジナルよりアーカイブ。2013年9月19日閲覧。
  32. ^ Cook, Tim (2009年11月16日). 「ZFSの自己修復のデモ」. blogs.oracle.com . 2011年8月12日時点のオリジナルよりアーカイブ。2015年2月1日閲覧。
  33. ^ Ranch, Richard (2007年5月4日). 「ZFS、コピー、そしてデータ保護」. blogs.oracle.com . 2016年8月18日時点のオリジナルよりアーカイブ。2015年2月2日閲覧。
  34. ^ ab "zpoolconcepts.7 — OpenZFS ドキュメント". openzfs.github.io . 2023年4月5日閲覧。
  35. ^ “ZFS Without Tears: ECCメモリなしでZFSを使用する”. www.csparks.com . 2015年12月. 2021年1月13日時点のオリジナルよりアーカイブ。2020年6月16日閲覧。
  36. ^ wdc.custhelp.com. 「デスクトップ版とRAID（エンタープライズ）版のドライブの違い」。2015年1月5日時点のオリジナルよりアーカイブ。 2011年9月8日閲覧。
  37. ^ abcd Bonwick, Jeff (2005年11月17日). 「RAID-Z」. Jeff Bonwickのブログ. Oracle Blogs. 2014年12月16日時点のオリジナルよりアーカイブ。2015年2月1日閲覧。
  38. ^ ab Leventhal, Adam (2009年12月17日). 「トリプルパリティRAIDとその先」. ACM Queue . 7 (11): 30. doi : 10.1145/1661785.1670144 .
  39. ^ 「ZFS Raidzのパフォーマンス、容量、整合性」calomel.org . 2017年11月27日時点のオリジナルよりアーカイブ。 2017年6月23日閲覧。
  40. ^ 「RAID 6が2019年に機能しなくなった理由」ZDNet 2010年2月22日。2014年10月31日時点のオリジナルよりアーカイブ。2014年10月26日閲覧。
  41. ^ 「ZFSにはfsckユーティリティに相当するものは存在しません。このユーティリティは従来、ファイルシステムの修復と検証という2つの目的を果たしてきました。」「ZFSファイルシステムの整合性チェック」Oracle。2013年1月31日時点のオリジナルからアーカイブ。 2012年11月25日閲覧。
  42. ^ “ZFS Scrubs”. freenas.org. 2012年11月27日時点のオリジナルよりアーカイブ。2012年11月25日閲覧。
  43. ^ 「デバイスを交換する前、またはプールの冗長性を一時的に低下させる前に、スクラブを実行して、すべてのデバイスが現在動作していることを確認する必要があります。」『ZFSベストプラクティスガイド』solarisinternals.com。2015年9月5日時点のオリジナルからアーカイブ。 2012年11月25日閲覧。
  44. ^ Jeff Bonwick. 「128ビットストレージ：あなたはハイですか？」oracle.com . 2015年5月29日時点のオリジナルよりアーカイブ。 2015年5月29日閲覧。
  45. ^ “ZFS: Boils the Ocean, Consumes the Moon (Dave Brillhart's Blog)”. 2015年12月8日時点のオリジナルよりアーカイブ。 2015年12月19日閲覧。
  46. ^ 「Solaris ZFS管理ガイド」。Oracle Corporation。2021年1月13日時点のオリジナルよりアーカイブ。 2011年2月11日閲覧。
  47. ^ 「ZFSファイルシステムの暗号化」。2011年6月23日時点のオリジナルよりアーカイブ。2011年5月2日閲覧。
  48. ^ 「安全なケーキを手に入れ、クローンも作成する（別名、ZFSによる暗号化＋重複排除）」。2013年5月29日時点のオリジナルよりアーカイブ。2012年10月9日閲覧。
  49. ^ “ZFS—Debian Wiki”. wiki.debian.org . 2019年9月8日時点のオリジナルよりアーカイブ。2019年12月10日閲覧。
  50. ^ 「提案：本番環境でZFSネイティブ暗号化とsend/recvを使用する際の警告を追加することを検討する」Github . 2024年8月15日時点のオリジナルよりアーカイブ。 2024年8月15日閲覧。
  51. ^ 「PSA: ZFSにはネイティブ暗号化と送受信時にデータ破損のバグがあります」Reddit . 2024年2月12日. 2024年8月15日時点のオリジナルよりアーカイブ。2024年8月15日閲覧。
  52. ^ 「ZFSの断片化：長期的な解決策」Github . 2024年8月15日閲覧。
  53. ^ 「ZFSの断片化を防ぐためのベストプラクティスとは？」Lawrence Systems . 2023年3月9日. 2024年8月15日時点のオリジナルよりアーカイブ。2024年8月15日閲覧。
  54. ^ 「Solaris ZFS がハイブリッドストレージプールを実現 - 経済性とパフォーマンスの障壁を打ち破る」(PDF)。Sun.com、2010年9月7日。 2011年10月17日時点のオリジナルよりアーカイブ(PDF) 。 2011年11月4日閲覧。
  55. ^ Gregg, Brendan. 「ZFS L2ARC」. Brendanのブログ. Dtrace.org. 2011年11月6日時点のオリジナルよりアーカイブ。 2012年10月5日閲覧。
  56. ^ Gregg, Brendan (2009年10月8日). 「ハイブリッドストレージプール：最高速度」. Brendanのブログ. Dtrace.org. 2016年4月5日時点のオリジナルよりアーカイブ。 2017年8月15日閲覧。
  57. ^ 「Solaris ZFSパフォーマンスチューニング：同期書き込みとZIL」Constantin.glez.de、2010年7月20日。2012年6月23日時点のオリジナルよりアーカイブ。 2012年10月5日閲覧。
  58. ^ abc “Release zfs-0.8.0”. GitHub . OpenZFS. 2019年5月23日. 2021年7月28日時点のオリジナルよりアーカイブ。 2021年7月3日閲覧。
  59. ^ 「ZFSオンディスク仕様」(PDF)。Sun Microsystems, Inc. 2006年。2008年12月30日時点のオリジナル(PDF)からアーカイブ。セクション2.4を参照してください。
  60. ^ “RAIDZ — OpenZFS ドキュメント”. openzfs.github.io . 2023年2月9日時点のオリジナルよりアーカイブ。 2023年2月9日閲覧。
  61. ^ Eric Sproul (2009年5月21日). 「ZFS Nuts and Bolts」. slideshare.net. pp.  30– 31. 2014年6月22日時点のオリジナルよりアーカイブ。 2014年6月8日閲覧。
  62. ^ 「ZFS Deduplication」。blogs.oracle.com。2019年12月24日時点のオリジナルよりアーカイブ。2019年11月25日閲覧。
  63. ^ Gary Sims (2012年1月4日). 「FreeNAS 8を使用したZFSベースのネットワーク接続ストレージの構築」. TrainSignal Training . TrainSignal, Inc. オリジナル（ブログ）から2012年5月7日時点のアーカイブ。 2012年6月9日閲覧。
  64. ^ Ray Van Dolson (2011年5月). 「[zfs-discuss] 要約: 重複排除メモリ要件」. zfs-discuss メーリングリスト. 2012年4月25日時点のオリジナルよりアーカイブ。
  65. ^ “ZFSTuningGuide”. 2012年1月16日時点のオリジナルよりアーカイブ。2012年1月3日閲覧。
  66. ^ Chris Mellor (2012年10月12日). 「GreenBytes brandishes full-fat clone VDI pumper」. The Register . 2013年3月24日時点のオリジナルよりアーカイブ。2013年8月29日閲覧。
  67. ^ クリス・メラー (2012年6月1日). 「新参者が箱から出して、全員に安く売る計画」The Register . 2013年8月12日時点のオリジナルよりアーカイブ。 2013年8月29日閲覧。
  68. ^ Chris Mellor (2014年12月11日). 「Dedupe, dedupe… dedupe, dedupe, dedupe: Oracle Polishes ZFS diamond」. The Register . 2017年7月7日時点のオリジナルよりアーカイブ。 2014年12月17日閲覧。
  69. ^ “Checksums and Their Use in ZFS”. github.com . 2018年9月2日. 2019年7月19日時点のオリジナルよりアーカイブ。2019年7月11日閲覧。
  70. ^ 「Solaris ZFS管理ガイド」第6章「ZFSファイルシステムの管理」 。2011年2月5日時点のオリジナルよりアーカイブ。2009年3月17日閲覧。
  71. ^ 「Smokin' Mirrors」. blogs.oracle.com . 2006年5月2日. 2011年12月16日時点のオリジナルよりアーカイブ。 2012年2月13日閲覧。
  72. ^ 「ZFSブロック割り当て」。Jeff Bonwickのブログ。2006年11月4日。2012年11月2日時点のオリジナルよりアーカイブ。 2007年2月23日閲覧。
  73. ^ 「Ditto Blocks — 驚異のテープ忌避剤」Flippin' off bits Weblog . 2006年5月12日. 2013年5月26日時点のオリジナルよりアーカイブ。2007年3月1日閲覧。
  74. ^ 「新しいディスクの追加とディットブロックの動作」。2011年8月23日時点のオリジナルよりアーカイブ。2009年10月19日閲覧。
  75. ^ "OpenSolaris.org". Sun Microsystems. 2009年5月8日時点のオリジナルよりアーカイブ。 2009年5月22日閲覧。
  76. ^ 「Solaris 11 Express 2010.11の新機能」(PDF)。Oracle。2010年11月16日時点のオリジナルよりアーカイブ(PDF) 。 2010年11月17日閲覧。
  77. ^ 「10. 共有 — FreeNAS ユーザーガイド 9.3 目次」. doc.freenas.org . 2017年1月7日時点のオリジナルよりアーカイブ。 2017年2月23日閲覧。
  78. ^ 「バグID 4852783: プール容量の削減」。OpenSolarisプロジェクト。2009年6月29日時点のオリジナルよりアーカイブ。 2009年3月28日閲覧。
  79. ^ Goebbels, Mario (2007年4月19日). 「プールからvdevを永久に削除する」. zfs-discuss (メーリングリスト).[永久リンク切れ] アーカイブリンク 2021年1月13日アーカイブ、 Wayback Machine
  80. ^ Chris Siebenmann 将来の vdev 削除に関する情報 アーカイブ 2016年8月11日、Wayback Machine、トロント大学、ブログ、引用: Alex Reece による非公式の Twitter 発表 アーカイブ 2016年8月11日、Wayback Machine
  81. ^ 「データ管理機能 - Oracle® Solaris 11.4の新機能」。2019年9月24日時点のオリジナルよりアーカイブ。2019年10月9日閲覧。
  82. ^ 「Expand-O-Matic RAID Z」、Adam Leventhal、2008年4月7日。2011年12月28日時点のオリジナルよりアーカイブ。2012年4月16日閲覧。
  83. ^ “ZFS Toy”. SourceForge.net . 2022年4月12日閲覧。
  84. ^ "zpoolconcepts(7)". OpenZFSドキュメント. OpenZFS. 2021年6月2日. 2021年4月12日閲覧.仮想デバイスはネストできないため、ミラーまたはraidz仮想デバイスにはファイルまたはディスクのみを含めることができます。ミラーのミラー（またはその他の組み合わせ）は許可されません。
  85. ^ "zpool(1M)". Download.oracle.com. 2010年6月11日. 2021年1月13日時点のオリジナルよりアーカイブ。2011年11月4日閲覧。
  86. ^ “Turbocharging ZFS Data Recovery”. 2018年11月29日時点のオリジナルよりアーカイブ。2018年11月29日閲覧。
  87. ^ “ZFS and OpenZFS”. iXSystems. 2019年6月18日. 2020年4月18日時点のオリジナルよりアーカイブ。2020年5月18日閲覧。
  88. ^ 「Sunが独自のストレージアプライアンスを発表」techworld.com.au、2008年11月11日。2013年11月13日時点のオリジナルよりアーカイブ。2013年11月13日閲覧。
  89. ^ Chris Mellor (2013年10月2日). 「Oracle、強力なZFSファイラーでベンチマークのトップに躍り出る」theregister.co.uk. 2017年7月7日時点のオリジナルよりアーカイブ。2014年7月7日閲覧。
  90. ^ 「iXsystemがシリコンバレーで構築した統合ZFSストレージアプライアンス」. ixsystems.com. 2014年7月3日時点のオリジナルよりアーカイブ。2014年7月7日閲覧。
  91. ^ ab “TrueNAS 12 & TrueNAS SCALE are officially here!”. ixsystems.com. 2020年10月29日. 2021年1月4日時点のオリジナルよりアーカイブ。2021年1月2日閲覧。
  92. ^ 「ReadyDATA 516—統合ネットワークストレージ」(PDF) . netgear.com. 2014年7月15日時点のオリジナルよりアーカイブ(PDF) . 2014年7月7日閲覧。
  93. ^ Jim Salter (2015年12月17日). 「rsync.net: クラウドへのZFSレプリケーションがついに登場—しかも高速」. arstechnica.com. 2017年8月22日時点のオリジナルよりアーカイブ。2017年8月21日閲覧。
  94. ^ rsync.net, Inc. 「SSH経由のZFS送受信によるクラウドストレージ」rsync.net. 2017年7月21日時点のオリジナルよりアーカイブ。 2017年8月21日閲覧。
  95. ^ Steven Stallion / Oracle (2010年8月13日). 「Update on SXCE」. Iconoclastic Tendencies. 2020年11月9日時点のオリジナルよりアーカイブ。2018年4月30日閲覧。
  96. ^ Alasdair Lumsden. 「OpenSolarisはキャンセルされ、Solaris 11 Expressに置き換えられる」osol-discuss（メーリングリスト）. 2010年8月16日時点のオリジナルよりアーカイブ。 2014年11月24日閲覧。
  97. ^ Solarisはまだオープンな状態だが、OpenSolarisディストリビューションは終了している。Ars TechnicaのWayback Machineに2017年9月5日アーカイブ。Ryan Paul著（2010年8月16日）
  98. ^ Garrett D'Amore (2010年8月3日). 「Illumos - Hope and Light Springs Anew - Presented by Garrett D'Amore」(PDF) . illumos.org. 2025年4月7日時点のオリジナルよりアーカイブ(PDF) . 2010年8月3日閲覧。
  99. ^ “Whither OpenSolaris? Illumos Takes Up the Mantle”. 2012年11月20日. オリジナルより2015年9月26日時点のアーカイブ。
  100. ^ Garrett D'Amore (2010年8月13日). “The Hand May Be Forced”. 2010年8月17日時点のオリジナルよりアーカイブ。2013年11月14日閲覧。
  101. ^ abc 「サン・マイクロシステムズの管理下にあった当時、Solaris Nevada（Solaris 10の後継となる次世代Solaris OSのコードネーム）のスナップショットが2週間ごとにリリースされ、この新しいコードはGenunix.orgで入手可能な新しいOpenSolarisプレビュースナップショットに取り込まれました。OpenSolarisの安定版リリースは、これらのNevadaビルドに基づいています。」ララベル、マイケル。「オラクルがOpenSolarisを支援か」Phoronix Media。2016年11月29日時点のオリジナルよりアーカイブ。 2012年11月21日閲覧。
  102. ^ Ljubuncic, Igor (2011年5月23日). 「OpenIndiana — there's still hope」. DistroWatch . 2012年10月27日時点のオリジナルよりアーカイブ。2012年11月21日閲覧。
  103. ^ “Welcome to Project OpenIndiana!”. Project OpenIndiana. 2010年9月10日. 2012年11月27日時点のオリジナルよりアーカイブ。 2010年9月14日閲覧。
  104. ^ “ZFSプールのバージョン”. Oracle Corporation. 2022年. 2022年12月21日時点のオリジナルよりアーカイブ。2023年1月1日閲覧。

参考文献

  • 渡辺, スコット (2009年11月23日). Solaris ZFS Essentials (第1版). Prentice Hall . p. 256. ISBN 978-0-13-700010-4. 2012年10月1日時点のオリジナルよりアーカイブ。
  • 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: ファイルシステムの最終形、ジェフ・ボンウィックとビル・ムーア著 (2017年8月29日アーカイブ)
  • 2013年4月、Aaron Toponce著、Wayback MachineでのZFSインテントログ（ZIL）の視覚化（2023年8月28日アーカイブ）
  • OpenZFSを含むillumosの機能
    • 以前のウィキページ（リンクがさらに追加されています）：ZFS入門、2014年9月15日（2018年12月30日アーカイブ）、illumosドキュメントの一部
Retrieved from "https://en.wikipedia.org/w/index.php?title=ZFS&oldid=1323889448"