ホームサーバーでは、スリープから復帰した後だけNVMeドライブが1台認識されなくなるのはなぜですか？
NVMeドライブは、復帰時にコントローラーまたはPCIeリンクが低電力状態から正常に戻れないと、スリープ後に見えなくなることがあります。
コールドブート後は正常に動作するのに、サスペンド後だけ消えるドライブは、通常、単純なファイルシステムの問題ではありません。名前空間、パーティション、ファイルシステム、アプリケーションが表示される前の段階で障害が発生している可能性があります。PCIeデバイスが再列挙されない、NVMeコントローラーが準備完了状態にならない、または電源管理の組み合わせによってリンクにアクセスできなくなる場合があります。まず最も下位の欠落レイヤーから診断し、デバイスパスを把握するまでは、ストレージのフォーマット、交換、再構築を行わないでください。
復帰後に消える最下位レイヤーを特定する
スリープ前に、PCIデバイス、NVMeコントローラー、名前空間、パーティション、ファイルシステムUUID、マウントポイント、ドライブを使用しているアプリケーションを記録します。復帰直後に同じ項目を再確認してください。
LinuxのNVMeサブシステムでは、コントローラーと名前空間は別々のレイヤーとして扱われます。Ubuntuのnvme listコマンドを使うと、コントローラー自体が見えないのか、コントローラーは残っているものの想定した名前空間を公開しなくなったのかを区別できます。
PCI機能が存在しない場合は、ファームウェア、PCIeリンクの電源管理、サスペンド動作に注目します。コントローラーが残っているのにブロックデバイスが消える場合は、NVMeのリセット、名前空間、ドライバーエラー、コントローラーの準備完了状態を確認します。
コールドブート、再起動、各スリープ状態を比較する
コールドブート、通常の再起動、アイドルへのサスペンド、そしてオペレーティングシステムとファームウェアが対応している場合のみディープサスペンドをテストします。どの遷移で障害が再現するかを記録してください。
Linuxカーネルでは、アイドルへのサスペンド、スタンバイ、RAMへのサスペンドを区別しており、それぞれデバイスとプラットフォームの電力削減レベルが異なります。カーネルのスリープ状態の説明では、浅い状態からは正常に復帰するNVMeコントローラーが、より深いプラットフォーム遷移後には失敗する理由を説明しています。
1つの状態に限って発生する障害は、ディスクフォーマットの問題よりも電源遷移の問題である可能性が高いことを示します。恒久的なファームウェアまたはドライバー修正をテストする間は、正常に動作する状態を利用できるようにしておきます。
PCIeデバイスが再列挙されるか確認する
スリープ前と復帰後のPCIバス出力を比較します。NVMeコントローラーのアドレス、ネゴシエートされたリンク状態、カーネルドライバー、エラーカウンターも含めて確認してください。テスト前に正確なバスアドレスを保存します。
lspciユーティリティは、名前空間やファイルシステムが関与する前のPCIレイヤーでコントローラーを表示するため、NVMeデバイス全体が消えたように見える場合の適切な切り分け手段になります。
PCI列挙からデバイスが消えている場合、ファイルシステムを再スキャンしたり、マウントを作り直したりしても解決しません。デバイスが表示されている場合は、コントローラーのリセットを試す前にNVMeとカーネルのエラーを記録してください。
NVMeの自律的な電源状態遷移をテストする
現在のNVMe電源状態設定と、自律的な電源状態遷移が有効かどうかを記録します。1回の制御されたサスペンドサイクルでは、電源関連の変数を1つだけ変更してください。
ArchWikiでは、NVMeの省電力動作と、特定のハードウェアで復帰が不安定な場合にコントローラーが移行できる低電力状態の深さを制限するためのAPST遅延制御について説明しています。
APSTの一時的な制限は診断手段であり、すべての深い電源状態に欠陥があることを証明するものではありません。より浅い電源ポリシーでのみドライブが繰り返し復帰できる場合は、回避策を恒久的に適用する前に、ファームウェアとカーネルの修正を比較してください。
ファームウェア、BIOS、モダンスタンバイの動作を確認する
マザーボードのファームウェアバージョン、NVMeファームウェア、オペレーティングシステムのビルド、最近行ったBIOSまたはドライバーの変更を記録します。プラットフォームが従来のスリープを使用しているのか、最新の低電力アイドルモデルを使用しているのかを確認してください。
Microsoftのモダンスタンバイモデルでは、対応デバイスが従来のスリープと同じ経路ではなく、プラットフォームが管理する低電力動作の対象になります。そのため、システムによってNVMeの問題の再現条件が変わることがあります。
ファームウェアレイヤーは一度に1つだけ更新し、以前のバージョンまたは復旧方法を確保しておきます。BIOS更新、SSDファームウェア更新、オペレーティングシステムのアップグレードを1回のテストで同時に行わないでください。どの変更で解決したのか特定できなくなります。
PCIeリンクの電源管理とランタイム電源管理を確認する
PCIe ASPM設定、ランタイム電源の状態、システムスリープ前にNVMeコントローラーがランタイムサスペンド状態へ移行しているかを確認します。サーバーの設計上安全な場合に限り、問題のあるスロットと別のスロットを比較してください。
Red Hatの電源管理ガイドでは、ランタイム電源管理とPCIe ASPMは別の仕組みであると説明されています。そのため、一方を無効にして変化が見られても、もう一方が原因だと自動的に判断することはできません。
問題がドライブとともに別のスロットへ移る場合は、コントローラーまたはファームウェアを疑います。1つのスロットに問題が残る場合は、マザーボードのファームウェア、レーン分岐、共有レーン、スロットへの電力供給、信号品質を確認してください。
安全に復旧し、復帰サイクルを繰り返し確認する
ドライブが消えた場合は、コールドシャットダウンを行う前にログを保存します。コントローラーが致命的な状態、リンクエラー、名前空間の消失を報告している場合は、ホットリセットを繰り返さないでください。
ZimaSpaceのホームサーバー復旧チェックリストにも、関連する原則があります。ファイルシステムの修復やデータの復元を実行する前に、ハードウェアの可視性とストレージの状態を確認してください。
意図した電源状態で、コントローラー、名前空間、パーティション、マウント、アプリケーションが繰り返しスリープおよび復帰サイクルを維持できれば、問題は解決したと判断できます。修正が再起動、アイドル時間、通常のストレージ負荷にも耐えることを確認するまで、最新のバックアップを保持してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
