解決策 1:
Seagate ディスク (場合によっては WD の古いディスクも) の場合、Seek_Error_Rate と Raw_Read_Error_Rate は 48 ビットの数値で、最上位の 16 ビットがエラー カウントで、下位 32 ビットが操作の数です。
% python
>>> 200009354607 & 0xFFFFFFFF
2440858991
>>> (200009354607 & 0xFFFF00000000) >> 32
46
したがって、ディスクは 2440858991 回のシークを実行し、そのうち 46 回が失敗しました。 Seagate ドライブに関する私の経験では、エラー数が 1000 を超えると故障する傾向があります。YMMV.
解決策 2:
「シーク エラー率」と「生の読み取りエラー率」RAW_VALUES は、Seagate のサポート以外には実質的に意味がありません。他の人が指摘したように、「再割り当てされたセクター数」などのパラメーターの生の値や、ドライブのエラー ログのエントリは、障害の可能性が高いことを示している可能性が高くなります。
ただし、ゲージとして読み取ることを意図した VALUE、WORST、および THRESH 列の解釈されたデータを見ることができます。
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH
7 Seek_Error_Rate 0x000f 077 060 030
つまり、シーク エラー率は現在「77% 良好」と見なされており、「30% 良好」に達すると SMART によって問題として報告されます。かつては「60% 良好」だったが、その後は魔法のように回復している。解釈された値はドライブの SMART ロジックによって内部的に計算され、正確な計算はメーカーによって公開されている場合と公開されていない場合があり、通常はユーザーが微調整することはできません。
個人的には、エラー ログ エントリを含むドライブを「故障」と見なし、エラーが発生したらすぐに交換することをお勧めします。しかし、Google が発表した研究論文が明らかにしたように、全体として、SMART データは故障予測のかなり弱い指標であることが判明しました.
解決策 3:
私の経験では、Seagate はこれら 2 つの SMART 属性に対して奇妙な数字を持っています。 Seagate を診断するとき、私はそれらを無視して、再割り当てセクター数などの他のフィールドを詳しく調べる傾向があります。もちろん、疑わしい場合はドライブを交換してください。ただし、真新しい Seagate でさえ、これらの属性の数値が高くなります。
解決策 4:
この議論は少し古いことに気付きましたが、私の 2 セントを追加したいと思います。スマートな情報は、故障前の非常に優れた指標であることがわかりました。スマートしきい値がトリップした場合は、ドライブを交換してください。それが、これらのしきい値の目的です。
ほとんどの場合、不良セクタが表示され始めます。これは、ドライブが故障し始めている確かな兆候です。 SMART は私を何度も救ってくれました。私はソフトウェア RAID 1 を使用していますが、故障したドライブを交換してアレイを再構築するだけなので非常に便利です。
また、短期および長期のセルフテストも毎週実行しています。
smartctl -t short /dev/sda
smartctl -t long /dev/sda
または、/etc/smartd.conf に追加して、エラーが発生した場合にメールで通知する
/dev/sda -s L/../../3/22 -I 194 -m [email protected]
/dev/sdb -s L/../../7/22 -I 194 -m [email protected]
logwatch をインストールし、ルートをメール アドレスにリダイレクトして、logwatch からの毎日のメールを確認してください。 SMARTD 作動フラグがそこに表示されますが、誰もそれを定期的に監視していなければ役に立ちません。
解決策 5:
この投稿でネクロマンシーをコミットして申し訳ありませんが、私の経験では、Seagate ドライブの「Raw Read Error Rate」および「Hardware ECC Recovered」フィールドは、文字通りいたるところに表示されます。 数兆の範囲に絶えず増加し、その時点でゼロに戻ってプロセスを再開します。私が持っている Seagate ST9750420AS は、初日からその問題を抱えていましたが、かなりの年数と 3500 時間以上使用した後でも問題なく動作します。
あなたのケースで実行している場合、これらのフィールドは安全に無視できると思います。 2 つのフィールドが同じ数値を報告し、常に同期していることを確認してください。そうでない場合は...まあ...それは実際には問題を意味する可能性があります.