SMARTの測定値を無条件に信頼してはいけない理由と、従来の「SMARTモニター」を常に使用しない方がよい理由についてもう一度友人に話したとき、話し言葉を一連の説明付きの形式で書き留めるというアイデアが思い浮かびました。毎回言い直すのではなく、リンクを提供するため。そして、幅広い聴衆に親しむために。
1）SMART属性の自動監視プログラムは、細心の注意を払って使用する必要があります。
SMART属性として知られているものは、すぐに保存されるのではなく、要求した瞬間に生成されます。これらは、動作中にドライブファームウェアによって蓄積および使用される内部統計に基づいて計算されます。
このデータの一部は、基本的な機能を提供するためにデバイスで必要ありません。また、保存されるのではなく、必要になるたびに生成されます。したがって、SMART属性の要求が発生すると、ファームウェアは、欠落しているデータを取得するために必要な多数のプロセスを起動します。
ただし、これらのプロセスは、ドライブに読み取り/書き込み操作がロードされたときに実行される手順との互換性が低くなります。
理想的な世界では、これが問題を引き起こすことはありません。しかし実際には、一般の人々はハードドライブ用のファームウェアを作成します。どちらが間違っている可能性があり、間違っています。したがって、デバイスが読み取り/書き込み操作をアクティブに実行しているときにSMART属性を照会すると、問題が発生する可能性が大幅に高まります。たとえば、ユーザーの読み取りまたは書き込みバッファー内のデータが破損します。
リスクの増加に関する記述は理論的な結論ではなく、実際的な観察です。たとえば、Samsung 103UI HDDのファームウェアで発生した既知のバグがあり、SMART属性の要求の実行中にユーザーデータが破損しました。
したがって、自動SMART属性チェックを構成しないでください。その前にFlushCacheコマンドが発行されていることが確実にわかっている場合を除きます。または、それなしでは実行できない場合は、チェックの実行をできるだけまれに構成します。多くの監視プログラムでは、スキャン間のデフォルトの時間は約10分です。それはあまりにも一般的です。とにかく、そのようなチェックは予期しないディスク障害の万能薬ではありません（万能薬は単なる冗長性です）。 1日1回-それで十分だと思います。
温度要求は、属性計算プロセスの開始にはつながらず、頻繁に実行できます。適切に実装されている場合、これはSCTプロトコルを介して行われるためです。すでに知られていることだけがSCTを通して与えられます。このデータはバックグラウンドで自動的に更新されます。
2）SMART属性データは信頼できないことがよくあります。
ハードドライブのファームウェアは、実際に起こっていることではなく、適切と思われることを示します。最も明白な例は、5番目の属性である再割り当てされたセクターの数です。データリカバリの専門家には、ハードドライブが存在し、表示され続けているにもかかわらず、5番目の属性でゼロの再割り当てを表示できることはよく知られています。
ハードドライブを研究し、ファームウェアを調べる専門家に質問しました。デバイスのファームウェアが、セクターの再割り当ての事実を隠す必要があると判断する原理は何であるかを尋ねました。これで、SMART属性を介してそれについて話すことができます。
彼は、デバイスが実際の画像を表示または非表示にする一般的な規則はないと答えました。また、ハードドライブファームウェアを作成するプログラマーのロジックは、非常に奇妙に見えることがあります。さまざまなモデルのファームウェアを調べたところ、「非表示または表示」の決定は、パラメーターのセットに基づいて行われることがよくあります。これらのパラメーターは、相互に、およびハードディスクの残りのリソースとどのように関連しているかが一般的に明確ではありません。
3）SMARTメトリックの解釈は、ベンダー固有です。
たとえば、Seagatesでは、属性1と7の「悪い」生の値に注意を払うべきではありませんが、残りは正常です。このメーカーのディスクでは、通常の使用中に絶対値が増加する場合があります。
ハードディスクの状態と残留リソースを評価するには、まず、パラメーター5、196、197、198に注意を払うことをお勧めします。さらに、特定の値ではなく、絶対的な生の値（生）に焦点を当てることは理にかなっています。属性のキャストは、アルゴリズムやファームウェアが異なると、自明ではない方法で実行できます。
一般に、メディアスペシャリストの間で、属性の値について話すとき、それは通常、意味される絶対値です。