質問が言うように。

FreeNASプール用のスクリプト化された「緊急ボタン」に相当するものが必要だとします。これは、クリックしてGUIから実行したり、コンソール/ SSHで実行したりできます。これにより、読み取りまたは書き込みを行う可能性のあるすべてのものがすばやく閉じられます。ファイルシステムをアンマウントし、理想的には、使用しているディスクまたはパーティションを静止します。

これを行ったり、長いファイル転送を途中で中止したりすることで他のソフトウェアやリモート接続に発生するエラーは気にしません。一貫性を維持し、場合によってはいくつかのファイルを与えることと一致する最速の方法でプールをオフラインにしたいだけです。保留中の書き込みが完了し、データの目的でプールが一貫した状態になるまでの秒数。

ZFSコマンドによって提案されたオプションは有望ではないようです：zpool offline 個々のデバイスでのみ機能するため、ディスクが一度に1つずつ削除されているときに書き込みが発生すると、競合状態が発生する可能性があります。 zpool export 使用中の場合は-fオプションが必要であり、-fという警告が表示されますデータも失う可能性があります。開いているすべてのfile descriptorsを確認できますプールまたはそのデバイス（数千または数十万？）を使用し、それぞれを手動で強制終了しますが、新しいfdの作成が同時に停止しないため、競合状態に陥る可能性があります。また、一部のファイルアクティビティはローカル（cron / CLI /デタッチセッション）である可能性が高いため、すべてのZFSアクティビティが終了シグナルを送信するリモートファイルサービングデーモンのリストによって仲介されると想定するべきではありません。

したがって、プール全体を安全かつ迅速にオフラインにする最善の方法を見ると、umountのように見えます。私の最善の策かもしれません-それはファイルシステムレベルで動作し、ファイルシステム全体をスピーディーにモノリシックユニットとしてオフラインにすることができ、その後zpool export -fがなくても、安全な方法で内部アクティビティを実際に終了して静止できるように見えます。オプション、データ自体を保証された一貫性のある状態に保ちます。生のディスクアクティビティ（resilverまたはscrub）が発生している場合は、後でプールがオンラインに戻ったときに再開または再開すると思います。

しかし、umountでさえ iSCSI zvolが存在する可能性があるため、完全には実行されていないようです。使用中のターゲットも同様です。サーバーはその構造を認識していないため、これらのデータ内のデータは本質的に一貫性を保つことができません。そのため、リモートイニシエーターは、再接続するときにできる限りデータを修復する必要があります。それで問題ありませんが、ターゲットを強制終了またはオフラインにするための何らかのコマンドが必要かどうか、またはベストプラクティスかどうかはわかりません。（注：接続を強制終了します個々のfdを閉じるのと同じ問題があります。）

書き込みが行われているときにプールが突然RW状態から追い出された場合、何らかのデータ損失または問題が発生する可能性があることを認識しています。ただし、（ZFSプールおよびファイルシステムレベルで）一貫性が失われない限り、それは問題ありません。更新される使用中のファイル/ iSCSIターゲットは、ZFSの一貫性があるファイル/ブロックでチャンスをつかむ必要があります。ただし、書き込まれているデータの途中でオフラインになるため、データが無効な状態になります。それは避けられないことであり、質問の問題ではありません。

したがって、プールの安全性と一貫性が保証された状態で、使用中のプールをできるだけ速くオフラインにするために、実際にどのような手順を実行する必要がありますか。手動でumount 使用中のZFSファイルシステムを（ソリューションの一部として）安全に使用するか、データが損傷するリスクがありますか？

更新： 他の誰かがこれが役に立つと思う場合に備えて、ここで言及します。受け入れられた回答は、export -f zvols（iSCSIなど）に問題がある可能性があります。このヒントに基づいて、FreeNASで使用されるiSCSIハンドラーはセッションを強制的にログアウト/終了でき、事前に発行できる他の便利なサブコマンドがあることがわかりました。man ctladmを参照してください。。 zvolがどのように使用されていても、それらのセッションを終了するためのコマンドが存在する可能性があります。）

承認された回答：

免責事項：現時点では、以下のすべてをバックアップするためのリンクや参照は多くありません。また、広範囲にわたってテストしていません。これは、過去5〜7年間にZFSとその仕組み、およびいくつかの限定された独自のテスト（調整されていないが、ほとんどがランダムな再起動）について読んだことの要約にすぎません。

また、以下のすべては、壊滅的なイベント（サーバーが完全に焼失する）、ソフトウェアのバグ（ZFSとメインオペレーティングシステムおよびハードウェアコントローラーのバグ）、およびアクティブな悪意（不正な管理者、管理エラー）を考慮せずに述べられています。これらすべての場合でも、定期的で復元可能なバックアップが必要です！

保存データ/ディスク上の整合性

これを行ったり、長いファイル転送を途中で中止したりすることで他のソフトウェアやリモート接続に発生するエラーは気にしません。一貫性を維持し、場合によってはいくつかのファイルを与えることと一致する最速の方法でプールをオフラインにしたいだけです。保留中の書き込みが完了し、データの目的でプールが一貫した状態になるまでの秒数。

まず、朗報です。ZFSはCoWとアトミックトランザクションを使用するため、突然の電力損失が発生した場合でも、既存のデータは安全になります。これには、プールのレイアウトとメタデータが含まれます。新しいデータが完全に書き込まれる前に古いデータが移動されることはないため（実際には、まったく移動されず、再割り当てされるだけです）、書き込みが突然中断された場合でも、このデータが危険にさらされることはありません。

関連：grep – grepパターンの角かっこがps結果からgrepプロセスを削除するのはなぜですか？

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

飛行中のデータ/書き込みモードと過去n秒間の損失

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

通常、ZFSは複数のトランザクションを収集して、ローテーションドライブへのコストのかかる書き込みを高速化します。HDDの書き込みヘッドの配置には実際の書き込みよりもはるかに時間がかかるため、できるだけ多くのキューに入れてから、順次（より高速に）書き込みます。！）注文（CoWがあることを思い出してください。これは、ここでは非常に自然に機能します）。

これの欠点は、収集に時間がかかるほど、アプリケーションが「書き込み成功」メッセージを待機する時間が長くなることです。これは、システムが数秒間ロックされることを意味し、これは受け入れられません。さらに悪いことに、電源障害が発生した場合、ディスクに書き込まれる予定であるがまだ書き込まれていないすべてのデータが失われます。アプリケーションがこれに対処できない場合、アプリケーション層で破損が発生する可能性があります。

これに対抗するために、ZIL（ZFSインテントログ）が追加されました。すべての同期トランザクションはこのログに収集され（デフォルトでは低速プールディスクに保存されますが、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のみを提供したため）。

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

standard 妥協点であり、最も柔軟性があります。アプリケーション自体が、必要な書き込みモードを決定します。アプリケーションが不良の場合、データ損失が発生する可能性があります。それらが動作する場合、安全性の特定のベースラインで可能な限り最高のパフォーマンスが得られます。

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

zpool exportに関するドキュメントから：

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

エクスポート時にデバイスが使用できない場合、デバイスは正常にエクスポートされたものとして識別できません。これらのデバイスの1つが、動作しているデバイスがない状態で後でシステムに接続された場合、「潜在的にアクティブ」であると表示されます。

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

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

-f すべてのファイルシステムがアクティブであっても（ロックやそこに書き込むアプリケーションを無視して）強制的にアンマウントすることにより、プールを強制的にエクスポートします。
これはzvolでは機能しません s
プールを分割して別のシステムで使用しないでください（フェイルオーバーの状況に注意してください）

関連：n番目に若いファイルをリストする方法（lsを解析せずに！）？

概要：

ディスク上の整合性だけが気になる場合は、export -fを使用することをお勧めします。または完全なシャットダウン
すべてのデータを気にする場合は、sync=alwaysを使用してくださいと高速SSD
VMのデータストアとしてのiSCSI/NFSに関しては、この概要も役立つ場合があります（抜粋：ゲスト/ VMホストでNFSを使用するか、iSCSIライトバックキャッシュを無効にします。ZFSスナップショットを作成する前にVMを静止します。とにかく、ZFSは問題ありませんがゲストVMはクラッシュコンシステントのみになります）

コメントからのフォローアップ質問への返信（有用な回答がない場合は省略した質問）：

（1）「朗報/牛」–トップレベルのブロックが更新されようとしている場合はどうなりますか–（メタデータツリーの少し古いバージョンを指している場合でも）常に使用可能なトップレベルのブロックが見つかりますか？それはどれほど悪くなることができますか？

最悪の場合、uberblock（他のすべてのデバイスの一番上にあるもの）がすべての冗長デバイスで損傷している可能性があります。その上にブロックがないため、上から再構築することはできません。そのため、各uberblockのコピーが複数存在し（IIRCは約3または4でした）、1つが失われ、代わりのコピーが残っている可能性があります。

（2）TXGに精通しており、ESXiを使用しています。 APCUPS+優れたPSU/hw + P3700 NVMe ZILを使用しているため、適切な電力+高速ZILです。しかし、現在の書き込みがすべて同期される可能性は低く、あなたが言うように、sync=alwaysは遅いです。しかし、あなたの返事は考えを提起します、私はいくつかのパフォーマンステストをするかもしれません。私は重複排除を使用しているので（4倍の節約、それだけの価値があります）、とにかくwrite =slowです（DDTを検索する必要があります）。 sync =常にである理由は、DDTのためにとにかく遅い書き込みにのみ影響します。ただし、sync =alwaysを設定するとZILが強制され、ZILは非常に高速であるため、長いTXGが安全になり、ディスクアクセスがより効率的になる可能性があります。または、レイテンシーを殺す可能性があります。どちらかわからない！試してみる必要があるかもしれません！

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

（6）「ディスク上の整合性」とは、ZFSが満足していて、プールが自己整合的であることを意味しますか？一部のファイル/ディレクトリがあれば心配ありません。無効なコンテンツになるか、移動/削除されないプールが突然消えるか、zvol上のNTFWS / VMFSなどのファイルシステムが内部的に破損します（つまり、ZFS zvolとしては問題ありませんが、クライアントの観点からはfsck / chkdskが必要です）。 ZFSが認識しているように、安全で一貫性があります

はい。本質的に「私のプールはめちゃくちゃではありません、イェーイ！」マルチユーザー設定の場合– 1人のユーザーが自分のファイルに問題を抱えていても、他のユーザーは問題を抱えていません。

（7）「クラッシュコンシステント」とは、私が意味することを意味します（私はあなたがそう思うと思います）– ZFSは正常であり、ZFSが認識している限り、プールは正常ですが、リモートクライアントのデータはそのクライアントのデータから破壊される可能性がありますクライアントが突然のディスクIO障害に遭遇し、書き込みが失われた場合と同様の観点ですか？ ==プールは正常であり、クライアントはデータを失った/一貫性がなく、他のディスクIO障害やシステムクラッシュと同様に、回復するための支援が必要な場合がありますか？

はい。基本的に、クリーンシャットダウンではなく、VMのハードパワーをオフにしてからスナップショットを作成します。後で電源をオンにすると、fsck または同様のファイルシステムが実行され、クリーンでないシャットダウンについて文句を言う場合があります。これは、何も起こらなかったかのように正確な時点で再開するESXiスナップショットとは対照的ですが、ゲストシステム（ゲスト追加がインストールされている）との対話が必要であり、VMの仮想メモリが含まれています。

両方を組み合わせることができます。最初にESXiスナップショットを作成し、次にデータストアのZFSスナップショットを作成します（ESXiはそのスナップショットをVMと一緒に保存します）。次に、ESXiスナップショットを削除しますが、ZFSスナップショットは保持します（ブロックレベルのコピーのため、必要なスペースははるかに少なくなります）。復元するときは、最初にZFSスナップショットを復元してから、（保存された）ESXiスナップショットに戻すと、中断したところから再開します。 napp-it（Webインターフェイスを備えた優れたZFS管理システム）には、この概念が組み込まれています（少なくとも、NFSデータストアでは、iSCSIをチェックしませんでしたが、類似していると想定しています）。