なぜSATA SSDはウォームリブート後に消えるのに、電源オフ後には再び認識されるのでしょうか？
SATA SSDは、コントローラーまたはリンクが不安定な状態のままになり、完全な電源切断でしか復旧しない場合、ウォームリブート後に見えなくなることがあります。
通常の再起動ではソフトウェアはリセットされますが、SSD、コントローラー、バックプレーン、またはマザーボードのポートに供給される待機電力が除去されないことがあります。リンクが準備完了状態にならないと、パーティション、ファイルシステム、プール、アプリケーションが関与する前にドライブが消える可能性があります。完全なシャットダウンでは、より深いレベルのコントローラーとリンクの初期化が強制されるため、診断結果が変わります。ストレージをすぐに再構築したりファイルシステムを交換したりするのではなく、まずデバイスが失われる最下層を特定してください。
SSDを失っているのがBIOS、SATAコントローラー、またはOSだけなのかを確認する
ウォームリブートの前後で、SSDがBIOSまたはUEFI、OSのコントローラー画面、ブロックデバイス一覧、パーティションテーブル、マウント済みファイルシステムに表示されるかを記録します。
LinuxのlibATAガイドでは、ドライバーがSATAリンクの準備完了を待機し、準備に失敗するとデバイスを存在しないものとして扱う場合について説明しています。このSATAリンクのリカバリーモデルにより、ファイルシステム層に到達する前にディスクが消える理由を理解できます。
BIOSでもSSDが見えなくなる場合は、ファームウェア、ポート電源、リンク初期化、ケーブル、ドライブコントローラーを確認します。BIOSでは認識されるのにOSで認識されない場合は、OSのログを保全し、ドライバーによる列挙とコントローラーモードを調べます。
ウォームリブート、完全シャットダウン、電源切断を比較する
通常の再起動、OSをシャットダウンしてすぐに電源を入れる操作、そして待機電源レールが低下するまで十分な時間を置いて電源を切断するシャットダウンをテストします。それぞれの状態を少なくとも2回繰り返してください。
PCIデバイスの表示は、コントローラーの存在とストレージの検出を切り分ける明確な境界になります。lspciユーティリティを使えば、SSDのブロックデバイスが存在しない場合でも、AHCIまたはSATAコントローラー自体が再起動前後で変化したかを確認できます。
完全な電源切断でのみドライブが復旧する場合、主な候補は、保持されたコントローラー状態、SATA PHYの不完全なリセット、SSDのファームウェア状態、または電源管理との相互作用です。このパターンは、通常のマウントやパーティションの問題とは考えにくいものです。
最初のSATAリンクとリセットエラーを調べる
コールドブートを実行する前に、ウォームリブートに失敗したときのカーネルログまたはシステムイベントログを保存します。リンクダウン、COMRESETの失敗、デバイス準備完了のタイムアウト、IDENTIFYコマンドの失敗、ポートリセットの繰り返しを示すメッセージを探してください。
SATAのアクティブリンク電源管理により、リンクが低電力状態になることがあります。一部のコントローラーとSSDの組み合わせでは、この状態を適切に処理できません。ArchWikiでは、積極的なリンク電源管理が、互換性のないデバイスで深刻な問題を引き起こす可能性があると警告しています。
ファイルシステムやプールが利用できないことを示す後続のメッセージより、最初に発生したエラーのほうが重要です。後で行うケーブル、スロット、ファームウェアのテストを同じ経路と照合できるよう、ポート番号とドライブモデルを保存してください。
SATAケーブル、電源コネクター、インターフェースエラーカウンターを確認する
サーバーの電源を完全に切った状態で、SATAデータケーブルと電源コネクターを差し直します。緩んだロックタブ、急な折れ曲がり、分岐ケーブル、バックプレーンコネクター、アダプターを点検してください。
Unraidのストレージトラブルシューティングガイドでは、UDMA CRCエラーが増加している場合、すぐにファイルシステムを修復するのではなく、データケーブル、電源ケーブル、コントローラー接続、ポートを確認するよう説明しています。
過去から蓄積されたCRCカウントだけでは、現在もケーブルに問題があるとは断定できません。現在の生の値を記録し、制御された再起動サイクルを1回実行して、カウンターが増加するか確認します。
SSDのSMART、エラーログ、ファームウェアの状態を確認する
ドライブが認識されている間に、SSDのモデル、シリアル番号、ファームウェアリビジョン、電源投入回数、異常シャットダウン回数、インターフェースエラー、利用可能なデバイスエラーログを取得します。
smartctlのリファレンスで説明されているSMART属性とエラーログは、フラッシュメモリの健全性に関する問題と、転送経路またはコントローラーの障害を切り分けるのに役立ちます。
SSDのファームウェアを更新する場合は、バックアップ、モデルの互換性、メーカーの復旧手順を確認してから実施してください。修正の効果を特定できるよう、ファームウェア層は一度に1つだけ変更します。
再スキャンは診断目的に限って使用する
コントローラーは認識されているのにディスクが見つからない場合は、アクティブなI/Oをすべて停止してから、対応しているストレージの再スキャンを1回実行します。電源サイクルなしでSSDが戻るかどうかを記録してください。
Microsoftは、DiskPartのrescanコマンドが新たに検出されたディスクを見つけると説明しています。これにより、OSによる検出の遅延と、コントローラーレベルでドライブが存在しない状態を区別できます。
再スキャンに成功しても、恒久的な解決ではありません。コントローラーとSSDが別の検出処理の後に通信できることを示しているだけなので、残る問題はファームウェア、ドライバー、コントローラーモード、またはリンク初期化にあります。
交換する前にドライブ、ポート、コントローラーを切り分ける
データをバックアップした後、正常動作が確認できているSATAポートとケーブルを使ってSSDを別のポートへ移すか、正常動作が確認できているドライブを元の経路でテストします。1サイクルにつき1つのコンポーネントだけを変更してください。
ZimaSpaceのSATAケーブルとドライブの障害を切り分けるガイドでは、断続的に失敗するストレージ経路に対する、隣接する切り分け手順を紹介しています。
SSDが繰り返しのウォームリブート、コールドブート、アイドル期間、継続的な読み取りのすべてで表示され続け、新たなリンクエラーも発生しなければ、問題は解決したと判断できます。正常なポートとケーブルでも消え続ける場合や、デバイスエラーが悪化している場合は、そのドライブを主要データ用として使うのを中止してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
