免責事項：現在、以下のすべての項目をバックアップできるリンクや参照はあまりなく、広範囲にテストしていません。これは、私がZFSについて読んだこと、そして過去5〜7年間でZFSがどのように機能するか、そして私が直接行ったいくつかの制限されたテスト（調整されていませんが、ほとんどランダムな再起動）の要約です。

さらに、以下に記載されているすべての内容は、致命的なイベント（完全なサーバーの使い果たし）、ソフトウェアのバグ（ZFSおよびネイティブオペレーティングシステムおよびハードウェアコントローラのバグ）、およびアクティブな悪意（悪意のある管理、管理エラー）を考慮していません。これらすべての状況でも、定期的で回復可能なバックアップが必要です！

未使用データ/ディスクの一貫性

他のソフトウェアやリモート接続によって引き起こされるバグや長いファイル転送を早期に中断することは気にしません。できるだけ早い方法でプールをオフラインにしたいです。これは一貫性を維持することと一致します。保留中の書き込みが完了し、プールがデータ整合性状態になった後の秒数を提供します。

まず、良いニュース：ZFSはCoWと原子トランザクションを使用しているため、突然の停電が発生しても既存のデータは安全です。これには、プールレイアウトとメタデータが含まれます。新しいデータが完全に書き込まれるまで、古いデータは移動されないため（実際にはまったく移動されず、単に再割り当てされます）、書き込みが突然中断されてもこのデータは危険ではありません。

また、チェックサム（マックルハッシュツリー）は、再起動中に問題が発生しなかったことを証明するのに役立ちます。これはプールをクリーンアップして確認できます。冗長vdevがある場合、ZFSは既知の良好なレプリカで見つかったすべてのエラーを自動的に修正します。一部のブロックが何らかの方法で破損している場合（書き込みを行わないが書き込みを主張する不良ディスクコントローラによって）、そのブロックのチェックサムは他のvdevのチェックサムと一致せず、エラーが表示されます。

フライト/書き込みモードのデータと最後のn秒のデータが失われます。

同期および非同期書き込み

通常、ZFS は、回転ドライブへの高価な書き込み速度を向上させるために複数のトランザクションを収集します。実際に書き込むよりもHDDの書き込みヘッドを配置するのに時間がかかるので、できるだけキューに入れてから順番に（より速く）書き込む必要があります！ ）注文（私たちにはCoWがあることを覚えておいてください。ここではこれは自然なことです）。

欠点は、収集時間が長くなるにつれて、アプリケーションが「書き込み成功」メッセージを待たなければならないことです。つまり、システムは数秒間ロックできず、これは許可されません。さらに悪いことは、電源が切れるとディスクに書き込もうとしましたが、まだ書き込まれていないすべてのデータを失うことです。アプリケーションがこの問題に対処できない場合、アプリケーション層の破損が発生する可能性があります。

この問題を解決するために、ZIL（ZFS Intent Log）が追加されました。すべての同期トランザクションはこのログに収集されます（デフォルトでは遅いプールディスクに保存されますが、SLOGデバイスと呼ばれる高速ミラーリングSSDに保存できます）。保存後に実行できるアプリケーションに「書き込み成功」が返されます。対応する操作（もはやロックがなくなります）また、すべての非同期トランザクションはZILなしで完了するため、アプリケーションがそのデータに対して正しい書き込み操作（同期対非同期）を呼び出す限り、速度が速くなる可能性があります。

ZFS プロパティ

今より興味深い部分が出てきます。あなたの投稿はどうなりますか？ここでは、ファイルシステムの動作モードを識別する必要があります（各ファイルシステムに対して個別に設定できるZFSプロパティ）。 3つの可能なモードは次のとおりです（マンページを参照）。

sync=standard
  This is the default option. Synchronous file system transactions
  (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
  and then secondly all devices written are flushed to ensure
  the data is stable (not cached by device controllers).

sync=always
  For the ultra-cautious, every file system transaction is
  written and flushed to stable storage by a system call return.
  This obviously has a big performance penalty.

sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.

選択しても、disabledプールレイアウト/内部一貫性は影響を受けません。最後の5秒のデータのみが失われますこれファイルを無効な状態にすることができます（たとえば、同期書き込みを必要とするVMが一番上にありますが、非同期zvolのみがバックアップデータストアとして提供されたため）。

一方、負けたくない場合何もない、少なくともSLOGデバイスの場合、すべてのファイルシステムをalways高性能SSDに設定して切り替えます（そうしないと待ち時間が発生します）。

standardトレードオフであり、最も柔軟な方法です。アプリケーション自体が必要な書き込みモードを決定します。アプリケーションが不良の場合、データが失われる可能性があります。パフォーマンスが良い場合は、特定のセキュリティ基準に対して最高のパフォーマンスを得ることができます。

プールのエクスポート/インポート：

~から文書についてzpool export：

このコマンドは、続行する前にプールにマウントされているすべてのファイルシステムをアンマウントしようとします。マウント解除できないファイルシステムがある場合は、-fオプションを使用して強制的にマウント解除できます。

エクスポート時にデバイスが利用できない場合、そのデバイスはクリーンエクスポートとして認識されません。後でこれらのデバイスのいずれかが動作しているデバイスがないシステムに接続すると、「潜在的なアクティビティ」と表示されます。

プールでZFSボリュームを使用している場合は、-fオプションを使用してもプールをエクスポートできません。 ZFSボリュームを含むプールをエクスポートするには、まずそのボリュームのすべてのコンシューマーがアクティブでないことを確認してください。

これはおよそ次の3つを意味します。

• -fアクティブな場合でも、すべてのファイルシステムを強制マウント解除してプールを強制的にエクスポートします（ロックまたはアプリケーションの書き込みに関係ありません）。
• zvolこれはsには適用されません。
• プールを分割して他のシステムで使用しないでください（注意してください）。フェイルオーバー状況)

要約：

• ディスク上の一貫性にのみ興味がある場合は、export -f完全にオフにすることを選択できます。
• すべてのデータに興味がある場合は、sync=always高速SSDを使用してください
• iSCSI / NFSをVMのデータストアとして考えてください。この概要役に立つかもしれません（抜粋：ゲスト/ VMホストでNFSを使用するか、iSCSI書き込みストレージキャッシュを無効にします。ZFSスナップショットを撮る前にVMを停止します。とにかくZFSは問題ありませんが、ゲストVMは常にクラッシュします）

コメントの後続の質問に対する回答（有用な回答がない質問は除く）：

（1）「良いニュース/COW」 - 最上位ブロックが更新されようとするとどうなりますか？ （メタデータツリーの少し古いバージョンを指している場合でも）常に利用可能な最上位ブロックを見つけます。どれくらい悪くなりますか？

最悪のシナリオは、すべての冗長デバイスでスーパーブロック（他のすべてのブロックの上にあるブロック）が破損することです。上記のブロックがないため、上で再構築できないため、各スーパーブロックのコピーが複数（約3〜4、IIRC）存在するため、1つが失われる可能性がありますが、代替コピーはまだ存在します。

(2) TXGに精通しており、ESXiを使用しています。 APC UPS +優れたPSU /ハードウェア+ P3700 NVMe ZILを使用するので、適切な電力+高速ZILを持っています。しかし、現在の書き込みがすべて同期される可能性は低く、言うようにsync = alwaysは遅いです。しかし、あなたの答えは私がいくつかのパフォーマンステストを実行できるという考えを引き起こしました。私はdedup（4倍の節約、それほど価値がある）を使っているので、とにかくwrite = slowです（DDTを探す必要があります）。これは、sync = alwaysがDDTのために遅い書き込みにのみ影響を与えるためです。ただし、sync = alwaysに設定すると、非常に高速なZILが強制され、長いTXGが安全になり、ディスクアクセスがより効率的になります。あるいは、遅延をなくすこともできます。どちらか分からない！たぶんそれを試す必要があります！

私は重複排除の実際の経験がないので、ハードウェア（低レイテンシ、高いランダム64k書き込みIOPS、NVMeインターフェイス）をうまく選択したこと以外はここで役に立つことを言うことはできません。非常に高価な永久RAMドライブ（ZeusRAM以外）に投資する場合にのみ速度が速くなります。

(6) 「ディスク上の一貫性」とは、ZFS が満たされ、プールが独自の一貫性を持つことを意味しますか？特定のファイル/ディレクトリについて心配しないでください。間違ったコンテンツで終わったり、プールが移動/削除されたり、突然消えたり、zvolのNTFWS / VMFSなどのファイルシステムが内部的に破損しています（例：ZFS zvolになるのは問題ありませんが、クライアントの観点からはfsck / chkdskが必要です）。 ）（プール提供）ZFSは安全で一貫性があると見なされます。

はい。本質的に「私の草は壊れませんでした！」マルチユーザー設定では、あるユーザーがファイルに問題があっても他のユーザーは影響を受けません。

(7) 「衝突一貫性」とはどういう意味ですか？ (そうであると仮定します。) - ZFS は問題ありません。ZFS の場合はプールも問題ありませんが、リモート クライアントのデータがクライアントのデータと異なる場合があります。データが難読化されました。突然のディスクIOエラーが発生し、書き込みが失われるクライアントと似ていますか？ ==プールは大丈夫です。他のディスクIOエラーやシステムクラッシュと同様に、クライアントにデータが失われたり一貫性がなく、回復に役立つ必要があるかもしれません。

はい、完全にシャットダウンしてからスナップショットを撮るのではなく、デフォルトでVMを強制終了します。後で電源を入れるfsckか、ファイルシステムが実行されるターゲットに応じて同様の場合、異常終了について文句を言うことができます。これは何も起こらなかったかのように正確な時点に復元されますが、ゲストとの対話（ゲスト追加インストール）が必要であり、仮想マシンの仮想メモリを含むESXiスナップショットとは対照的です。

2つを組み合わせることで利点を得ることができます。まず、ESXiスナップショットを作成してから、データストアのZFSスナップショットを作成します（ESXiはスナップショットを仮想マシンに保存します）。その後、ESXiスナップショットを削除し、ZFSスナップショットを維持します（ブロックレベルのコピーのためにはるかに少ないスペースを占有します）。復元するときは、まずZFSスナップショットを復元し、次に（保存された）ESXiスナップショットに復元してから、中断した部分から再起動します。 napp-it（Webインターフェースを備えた優れたZFS管理システム）には、この概念が組み込まれています（少なくともNFSデータストアの場合、iSCSIを検証しなかったが類似していると仮定します）。