すべてのアプリコンテナを停止した後もBtrfsスナップショットが使用中のままになるのはなぜですか？
停止したコンテナによって、別のプロセス、マウント名前空間、バインドマウント、送信ジョブ、またはネストされたサブボリュームが参照している場合、Btrfs スナップショットが使用中のままになることがあります。
アプリケーションコンテナを停止するとメインプロセスは終了しますが、関連するすべてのマウント、ヘルパープロセス、ランタイムシム、シェルセッション、バックアップジョブ、名前空間がスナップショットのパスを解放したことを意味するわけではありません。Btrfs は、対象がマウントされている場合、送信に使用中の場合、デフォルトサブボリュームとして設定されている場合、またはネストされたサブボリュームを含んでいる場合にも削除を拒否することがあります。強制アンマウントやコンテナデータの削除を行う前に、正確な参照元を特定してください。
正確な Btrfs オブジェクトとエラーを確認する
スナップショットの完全なパス、サブボリューム ID、親 ID、読み取り専用状態、UUID、受信 UUID、および削除時に表示された正確なエラーを記録します。そのパスが、サブボリューム内の通常のディレクトリではなく、Btrfs サブボリュームであることを確認してください。
Btrfs サブボリュームのリファレンスでは、スナップショットがサブボリュームであることが説明され、デフォルトサブボリュームとしての状態やアクティブな送信操作など、削除を妨げる条件も記載されています。
エラーが EBUSY ではない場合は、実際の失敗内容に従って対処してください。権限、読み取り専用マウント、デフォルトサブボリューム、ネストされたサブボリュームの問題には、アクティブなマウント参照とは異なる確認が必要です。
コンテナの停止と削除を分けて考える
実行中、停止、異常終了、削除中の各状態にあるコンテナを一覧表示します。バインドマウント、名前付きボリューム、または Btrfs ストレージドライバーを通じてスナップショットを使用していたコンテナ ID を記録してください。
Docker の CLI リファレンスでは、docker stop がメインプロセスにシグナルを送ることが説明されています。これは、コンテナ定義、ランタイムメタデータ、またはホスト側のすべてのストレージ関連付けが削除されたことを意味しません。
アプリケーションの UI にスタックが停止したと表示されているだけで、スナップショットを削除しないでください。再起動ポリシー、ヘルスチェック用ヘルパー、exec シェル、サイドカー、またはコンテナランタイムのプロセスが残っていないか確認します。
関連するすべての名前空間でマウントを確認する
ホストのマウントテーブルを、コンテナランタイム、停止したコンテナのヘルパー、バックアップエージェント、およびコンテナに入ったままの長時間稼働シェルのマウント名前空間と比較します。
Linux のマニュアルでは、マウント名前空間がマウント一覧を分離することが説明されています。そのため、ホスト上ではアンマウントされているように見えるパスが、別のプロセス名前空間内ではマウントされたままになっている可能性があります。
現在のシェルだけを確認せず、プロセスごとのマウント情報を使用してください。ホストからの遅延アンマウントでは、症状を隠せても、参照を保持している名前空間を解放できない場合があります。
別の名前空間に残っているコンテナマウントを探す
名前空間を保持している可能性のあるコンテナランタイム、シム、監視エージェント、またはヘルパーのプロセス ID を特定します。そのマウントツリーと、Btrfs スナップショットに対応するソースパスを確認してください。
Red Hat では、別の名前空間にあるマウントがデバイスまたはリソースの使用中エラーを伴うクリーンアップを引き起こす事例を検証しています。これは、ホスト上では問題がないように見えても、スナップショットが参照され続ける状況と一致します。
明らかに古いと確認できたヘルパーだけを終了するか、メンテナンス時間帯に関連するランタイムを再起動してください。無関係な名前空間の所有者を強制終了すると、他のコンテナやマウントに影響する可能性があります。
名前空間の制限を考慮して fuser とオープンハンドルを確認する
スナップショットのパスに対して、オープンファイル、カレントディレクトリ、メモリーマップされたファイル、マウントの使用者を確認します。十分な権限でツールを実行し、検出されたプロセス一覧をランタイムのプロセスと比較してください。
Debian の fuser マニュアルでは、別のマウント名前空間のプロセスによってマウントされたブロックデバイスが検出されない場合があると警告しています。そのため、結果が空でもスナップショットが未使用だとは証明できません。
また、スナップショット内をカレントディレクトリにしているシェルセッション、ファイルインデックスサービス、ウイルス対策スキャナー、バックアップの読み取り処理、アプリケーションログの追跡プロセスも確認します。確認できた使用者を一つずつ終了し、読み取り専用の状態確認を再実行してください。
マウント済み、デフォルト、ネスト、送信中のサブボリュームを除外する
スナップショットのサブボリューム ID に解決されるすべてのマウントを一覧表示し、ファイルシステムのデフォルトサブボリュームを確認し、ネストされた子サブボリュームを列挙して、アクティブな Btrfs 送信ジョブを調べます。
ArchWiki では、マウントされたサブボリュームは削除すべきでないことが案内されています。削除前には、マウントの識別情報とネスト構造を確認する必要があります。
アプリコンテナを停止しても、独立した Btrfs の送信、スナップショットのレプリケーション、バックアッププロセスは停止しません。送信が完了するまで待つか、適切に停止してから、スナップショットの状態を再確認してください。
確認済みの参照を解放して安全に削除する
参照を保持している名前空間でスナップショットをアンマウントし、必要に応じて古いコンテナランタイムオブジェクトを削除または再起動し、作業ディレクトリから移動し、確認済みの送信タスクを停止して、依存関係の順序に従ってネストされたサブボリュームを削除します。
ZimaSpace のNAS アプリデータのスナップショットに関する記事では、コンテナのスナップショットが実際に対象とする永続パスやアプリケーションの状態を特定するための関連情報を確認できます。
名前空間やプロセスがサブボリュームを参照しておらず、正しい非デフォルトのスナップショットがサポートされている Btrfs コマンドで削除でき、バックグラウンドのクリーンアップが完了し、アプリケーションスタックが本来のライブデータパスを維持したまま再起動できれば、問題は解決しています。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
