SSD の健全性は紛らわしい指標になる可能性があり、多くの人がそれを議論するときにまったく異なるものを参照します。しかし、NVMe SSD にはコントローラー内に実際のエラー ログがあり、オペレーティング システムが時折驚くような漠然とした警告よりもはるかに有益であることをご存知ですか?
このログを取得して読む方法を学べば、無害な問題と差し迫ったドライブ障害の違いを見分けることができるでしょう。
NVMe SSD には実際のエラー ログがあり、いいえ、SMART と同じものではありません
これは、ドライブの何が問題なのかを解明するのに役立つかもしれません
SSD は素晴らしいものですが、問題が発生する可能性もたくさんあります。彼らは、コンセントに接続されていない状態で、何年も一人で放置されることを好みません。彼らはランダムに姿を消し、あなたを雁の追跡に駆り立てる可能性があります。また、健康状態が 100% の場合でも失敗する可能性があります。
これらのことはすべて真実ですが、別のことも真実です。SSD は詳細なエラー ログを保持しており、故障したドライブを診断する必要がある場合や、現時点では正常であることを知らせたい場合に役立ちます。
問題は、オペレーティング システムがこのログをランダムに表示する可能性が低いことです。それを掘り下げて、それを理解する方法を学ぶ必要があります。
OS レベルの警告は、多くの場合単なる症状です。タイムアウト、リセット、一般的な「ディスクに問題があります」アラートなど。コントローラーのエラー ログはこれらの多くを追跡しており、Windows アラートの曖昧な性質を超えて実際に何が起こったのかを確認できる場合があります。
ただし、これは SMART とは異なります。 SMART ヘルス トラッカーは主にカウンターと摩耗インジケーターです。私はそれらが大好きで熱心に使用していますが、SSD は適切な SSD の維持とメンテナンスのほんの一部にすぎません。 NVMe エラー ログは、最近の障害やイベントの記録に一歩近づき、SSD の状態をより包括的に把握できるようになります。
それを見つけるのはそれほど難しくありません
少し掘り下げる必要があります
では、この神話的な NVMe エラー ログはどこで見つけられるのでしょうか?いくつかの方法があります。
Windows の場合、最も簡単なルートは Smartmontools です。これは、SSD/NVMe の正常性データとログを読み取ることができる、無料のオープンソースで広く使用されているドライブ診断ツールのセットです。 Windows、Linux、macOS で利用できます。これは、ユーザーと NVMe コントローラーの間に失われたリンクです。 Windows は、ドライブが正常であることを通知しますが、コントローラー自体のエラー ログは表示しないため、非表示の NVMe ログを取得してドライブ自体が記録している内容を確認する場合は、特に Smartctl (Smartmontools の一部) を使用します。
最初のステップ: ツールをインストールします。次に、管理者として PowerShell を開き (Windows の場合)、次のコマンドを実行します。
smartctl --scan-openこれにより、正しいデバイス名が見つかります (Windows では、通常、\\.\PHYSICALDRIVE1 または \\.\nvme0 のようになります)。次に、以下を実行します。
smartctl -l error \\.\PHYSICALDRIVE1これにより、NVMe エラー情報ログが出力されます (スキャンした名前に置き換えることを忘れないでください)。最後に、より幅広いコンテキストについては、次を実行します。
smartctl -a \\.\PHYSICALDRIVE1これには、NVMe ヘルス カウンターも含まれており、1 回限りのエラーか、より大きなパターンのどちらかを判断するのに役立ちます。
実用的な注意事項: NVMe ドライブが USB エンクロージャまたは特定の RAID レイヤーの背後にある場合、smartctl は NVMe 管理コマンドを通過できない可能性があります。その場合、ログはまだ存在します。読み取るには、直接 M.2 スロット上のドライブが必要です (または NVMe パススルーをサポートするスタックを使用します)。
推測せずに NVMe エラー エントリを読み取る方法
すべては構造化されており、潜在的に重要である
NVMe エラー情報ログにアクセスすると、通常、エントリ全体で同じ少数のフィールドが繰り返し表示されます。 ErrCount、SQId、CmdId、ステータス、PELoc、LBA、 そして NSID。それを理解するのは面倒に感じるかもしれないので、少し分解してみましょう。
まずステータスから始めます。これは、コントローラがログに記録したと考えているエラーの種類を正確に示すからです。他の列では、それが実際の I/O コマンドに関連付けられているのか、それとも単なるバックグラウンド ノイズに関連付けられているのかを知ることができます。
ErrCount はパンくずリストのようなものです。これは、ログに記録されたイベントごとに増加する一意の識別子であり、システムは電源を入れ直してもそれを保持する必要があるため、ErrCount の上昇は単に新しいエントリが作成されたことを意味します。そこにはニュースはありません。
一方、SQId と CmdId は、エラーが特定のコマンド キュー/ID にマップされているかどうかを示します。 「該当なし」に設定されている場合、それは一般的なものまたは非同期的なものである可能性があり、失敗した特定のファイル書き込みを示しているわけではありません。
次に、PEloc (パラメータエラー位置) に進みます。これは完全な診断ではなく、別のパンくずリストです。ステータスがコマンドまたはパラメータの問題のように見える場合、PELoc は基本的に、送信されたものが気に入らなかったバイトおよびビットをポイントしているコントローラです。
最後に、LBA と NSID です。多くのエラー タイプ (特にホスト側または管理コマンドの問題) では、エラーが特定のデータ ブロックに関連付けられていないため、LBA フィールドは単純にゼロになります。どのブロックが失敗したかを正確に知る必要がある場合は、デバイスのセルフテスト ログとその失敗した LBA データで答えを探し、それをメディア エラーやデータ整合性エラーなどのヘルス カウンタと関連付けます。
本当に心配する必要がある警告はどれですか?
警報が出たからといって大惨事になるわけではない
エラー ログでエラーを見つけることは、自動的に「パニック モードに入る」ようなものではありません。 (私がそう言ったのは、数十年自分の PC を扱ってきた後でも、通常、それが私の反応だからです。)
それはむしろ警告として扱ってください。そうは言っても、一部のステータスは絶対に真剣に受け止める必要があります。書き込みエラーや未回復読み取りエラーなどのメディアおよびデータの整合性スタイルのステータスが表示された場合、それはコントローラーが NAND にデータをコミットできなかったか、NAND からデータを回復できなかったことを示しています。残念ながら、それは決して良いニュースではありません。
逆に言えば、恐ろしいと思われる多くのエラーは、ホスト側からの単なるノイズです。ドライバーおよび監視ツールは、オプションのコマンドまたはサポートされていないコマンドを試行することがあります。実際には何も悪いことが起こっていないにもかかわらず、SSD がそれをエラーとして記録することがあります。それは単に未知の、または珍しいものでした。それでも、後悔するよりは安全な方が良いですよね?
パターンを探してから行動する
実際に本当に重要なのは、パターンがある場合、そのパターンです。同じエラーが頻繁に発生しますか?それらはフリーズ、リセット、その他の憂慮すべき兆候と一致していますか?ヘルスカウンターも同様に上昇傾向にありますか?
「はい」の場合、新しい SSD を購入するか、少なくともバックアップ用の 3-2-1 ルールに従うことについて、より真剣に検討し始める時期が来たことを意味する可能性があります。データ損失が発生する可能性がありますが、備えがあれば、それは単なる迷惑にすぎません。
7/10
- ストレージ容量
-
1TB、2TB、4TB、8TB
- ハードウェアインターフェース
-
M.2 NVMe
Samsung 9100 Pro は、現在入手できる最高の SSD の 1 つです。安くはありませんが、ほとんどの SSD はそうではありません。ただし、少なくとも価格を考えると信頼できます。