ZFSデータセットが正常にマウントされたのに空に見える原因は？
ZFSデータセットがマウント済みと表示されているのに空に見える場合、想定しているデータが子データセットに存在する、マウントポイントの下に隠れている、または異なるインポートルートにある可能性があります。
マウント済みのフラグが示すのは、1つのデータセットが1つのパスに接続されていることだけです。そのパスがアプリケーションやユーザーの想定する場所であること、子データセットがその下にマウントされていること、暗号化された子孫データセットがアンロックされていることまでは保証しません。空の親データセットが完全に正常で、実際のファイルがすべて子データセットに保存されている場合もあります。データをコピーしたりプール構成を変更したりする前に、データセットのプロパティ、参照領域、マウントテーブル、ディレクトリの表示内容を比較してください。
データセットの使用領域と開いたディレクトリを比較する
データセット名、USED、REFER、AVAIL、MOUNTPOINT、MOUNTED の値を記録します。次に、ユーザーまたはアプリケーションに表示されている正確なディレクトリを一覧表示します。
データセットの参照データがほとんどない場合、ファイルは子データセット、スナップショット、クローン、または似た名前を持つ別のデータセットに属している可能性があります。FreeBSDのZFSハンドブックでは、データセットは個別に管理されるファイルシステムと説明されているため、プール全体の使用量と、開いた1つのディレクトリが同じデータセットを表すとは限りません。
グラフィカルなファイルブラウザーだけを見て、データが失われたと判断しないでください。ZFSのプロパティ表示、オペレーティングシステムのマウントテーブル、コンテナや制限されたアプリケーションの名前空間の外にあるローカルのrootシェルを比較します。
mountpoint、mounted、canmountをまとめて確認する
データセットのマウントポイントが明示的に設定されているか継承されているか、そのパスに実際にマウントされているか、さらに canmount が on、off、noauto のどれになっているかを確認します。
OracleのZFSプロパティに関する説明では、mountpointとcanmountによって、データセットを自動的にマウントするか、要求されたときだけマウントするか、または子孫データセットにプロパティを渡すためだけに使用するかが決まると説明されています。
データセット自体は意図的にマウントされていなくても、子データセットに継承プロパティを提供できます。一方、legacy マウントポイントを使用するデータセットは、ZFSのプロパティ上は正しく見えても、実行されなかった別のシステムマウント設定に依存している場合があります。
親データセットと子データセットのマウントを確認する
プール以下のデータセットツリー全体を一覧表示し、マウントポイント順に並べます。親データセットと、ユーザーファイル、アプリケーションデータ、バックアップ、メディアが保存されるはずのすべての子データセットを比較します。
プロパティやマウントポイントを整理する目的だけで存在する親データセットが空なのは、よくあることです。FreeBSDのZFSデータセット名前空間では、各子データセットが個別に管理されるため、pool/data が空でも、実際のファイルは pool/data/photos に保存されている可能性があります。
親はマウントされているのに子がマウントされていない場合は、子データセットを個別に診断します。canmount、暗号化キー、競合するマウントポイント、インポートの失敗、子データセットのマウントが完了する前にサービスが起動していないかを確認してください。
マウントによってディレクトリ内の既存ファイルが隠れていないか確認する
データセットがそのディレクトリにマウントされる前から、通常のディレクトリ内にファイルが存在している場合があります。ZFSデータセットをマウントすると、その下にあるファイルはrootファイルシステム上に残ったままですが、そのパスからは見えなくなります。
データセットのアンマウントは、管理されたメンテナンス時間内でのみ行い、ホストから下層のディレクトリを確認してください。Linuxのmountマニュアルでは、マウント前から存在するマウントポイントの内容は見えなくなると説明されています。
逆の問題も起こります。想定していたZFSのマウントに失敗すると、空の下層ディレクトリがユーザーやコンテナに表示されます。そのため、正常なデータセットが空に見えることがあります。実際には、サービスが提供するパスに接続されていないだけです。
代替ルートとlegacyマウントの動作を除外する
プールが代替ルート、リカバリオプション、一時的なマウントパス、または異なるプール名でインポートされていないか確認します。データセットが正常にマウントされていても、通常の本番環境の場所ではなく、一時的なリカバリパスの下にマウントされている可能性があります。
代替ルートを指定してプールをインポートすると、その一時的なルートを基準にデータセットのマウント場所が書き換えられます。Ubuntuのzpool importリファレンスでは、-R が altroot を設定し、-N を使うとファイルシステムをマウントせずにインポートできると説明されています。
マウントポイントが legacy になっているデータセットも確認します。このモードではZFSがマウントを自動管理しないため、オペレーティングシステムのマウント設定が信頼すべき情報源になります。
暗号化された子データセットとコンテナのマウント名前空間を確認する
暗号化された子データセットは、親がマウントされた後でも、キーが読み込まれていない、または子のマウントに失敗した場合は利用できないことがあります。その場合、プールがオンラインでも親ディレクトリが空または不完全に見えます。
暗号化されたすべての子孫データセットについてキーの状態とマウント状態を確認し、ホストのパスとコンテナに表示されるパスを比較します。CanonicalのLXDドキュメントでは、コンテナのディスクデバイスがホストのソースを対応するインスタンスパスに割り当てると説明されています。そのため、ホストから見える子データセットが、古いコンテナのマウントには存在しない場合があります。
ホストからはデータが見えるのにコンテナから見えない場合は、コンテナのバインドソースとマウント伝播を確認します。ZFSの子データセットがマウントされる前に作成されたコンテナでは、サービスを再作成するか、マウントを正しく伝播させるまで、下層の空のディレクトリが表示され続けることがあります。
データセットをコピーせずに正しい表示を復元する
問題があると確認できた最小限のプロパティまたはパスだけを修正します。マウントされていない子データセットをマウントする、継承されたマウントポイントを修正する、意図しない代替ルートを削除する、legacyのマウントエントリを修復する、暗号化キーを読み込む、または正しいバインドソースでコンテナを再作成します。
ZimaSpaceのホームサーバー復旧チェックリストにも関連する原則があります。修復ツールを実行したりデータを復元したりする前に、ストレージ層とマウント状態を確認してください。
想定したデータセットと子データセットのマウントが意図したパスに表示され、参照領域が表示されているファイルと一致し、アプリケーションがホストと同じツリーを認識し、エクスポート、インポート、サービスの再起動、再起動後も構成が維持されれば、診断は完了です。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
