このsmartctl（smartmon）データを解釈する方法
3年間使用されているLinuxサーバーがあります。私たちはその上でいくつかの仮想サーバーを実行していますが、一部は正常に動作しておらず、かなりの期間、サーバーのio容量を超えてiowaitが不良になりました。 3com RAIDコントローラーに接続された4つの500GBのバラクーダSATAドライブがあります。 1つのドライブにOSがあり、他の3つはRAID 5のセットアップです。
ここで、ドライブの状態と、ドライブがアクティブに故障しているかどうかについての議論があります。
以下は、4つのディスクのうちの1つの出力の一部です。それらはすべて比較的類似した統計を持っています：
SMART属性データ構造のリビジョン番号：10 ベンダー固有SMARTしきい値のある属性： ID＃ATTRIBUTE_NAMEフラグ値最悪のしきい値タイプが更新されましたWHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always-169074425 3 Spin_Up_Time 0x0003 095 092 000 Pre-fail Always-0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always-26 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always-0 7 Seek_Error_Rate 0x000f 077 060 030 Pre-fail Always-200009354607 9 Power_On_Hours 0x0032 069 069 000 Old_age Always-27856 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always-1 12 Power_Cycle_Count 0x0032 100 100 020 Old_age A lways-26 184 Unknown_Attribute 0x0032 100 100 099 Old_age Always-0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always-0 188 Unknown_Attribute 0x0032 100 100 000 Old_age Always-1 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always-0 190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age Always-29（Lifetime Min/Max 26/37） 194 Temperature_Celsius 0x0022 029 040 000 Old_age Always -29（0 21 0 0） 195 Hardware_ECC_Recovered 0x001a 046 033 000 Old_age Always-169074425 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always-0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_ageオフライン-0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_ age常に-0 SMARTエラーログバージョン：1 エラーは記録されません
これについての私の解釈は、ドライブのいずれかがアクティブに故障しているという不良セクターやその他の兆候はなかったということです。
ただし、高いRaw_Read_Error_RateおよびSeek_Error_Rateは、ドライブが故障していることを示すものとして指摘されています。
私の経験では、シーゲイツはこれら2つのSMART属性に奇妙な数字を持っています。シーゲイトを診断するとき、私はそれらを無視して、再割り当てセクター数のような他のフィールドをよりよく見る傾向があります。もちろん、疑わしい場合はドライブを交換しますが、新品のSeagateでもこれらの属性の数は多くなります。
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。
「シークエラーレート」および「生の読み取りエラーレート」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ロジックによって内部的に計算され、正確な計算は製造元によって公開されている場合とされていない場合があり、通常はユーザーが調整しました。
個人的には、エラーログエントリが含まれているドライブを「障害」と見なし、エラーが発生したらすぐに交換するように促しています。しかし全体として、SMARTデータは Googleが発行した研究論文 が明らかになったように、故障予測のかなり弱い指標であることが判明しました。
私はこの議論が少し古いことに気づきましたが、私の2セントを追加したいと思います。スマートな情報は、事前障害のかなり良い指標であることがわかりました。スマートしきい値が作動した場合は、ドライブを交換してください。それがこれらのしきい値の目的です。
時間の大部分は、不良セクターを見始めます。これは、ドライブが故障し始めているという確かな兆候です。 SMARTは私を何度も救ってくれました。私はソフトウェアRAID 1を使用しており、故障したドライブを交換してアレイを再構築するだけなので非常に役に立ちます。
また、週に1回は短期および長期のセルフテストを実施しています。
smartctl -t short /dev/sda
smartctl -t long /dev/sda
または、/ etc/smartd.confを追加して、エラーが発生した場合にメールで送信します
/dev/sda -s L/../../3/22 -I 194 -m someemail@somedomain
/dev/sdb -s L/../../7/22 -I 194 -m someemail@somedomain
Logwatchをインストールしてrootをメールアドレスにリダイレクトし、logwatchからの毎日のメールを確認してください。 SMARTDトリップフラグが表示されますが、定期的に監視している人がいない場合は役に立ちません。
はい、これらのフィールドは見た目が悪いですが、スマートから報告された情報は（もう）信用していません（私のテストマシンには、smartctrlでデータを読み取る場合、かなり前にドライブが停止しているはずです）。高いiowaitとドライブは3年前のものです。ドライブを変更するにはこれで十分です。
この投稿でネクロマンシーをコミットして申し訳ありませんが、私の経験では、Seagateドライブの「Raw Read Error Rate」フィールドと「Hardware ECC Recovered」フィールドは文字通り文字通り移動しますすべての場所で、常に増加します数兆の範囲で、その時点で彼らは再びゼロに戻ってプロセスを続行します。私はSeagate ST9750420ASを持っています。最初からその問題があり、かなりの数年と3500時間以上の使用後でさえもうまく機能します。
あなたがあなたのケースで1つを実行しているなら、それらのフィールドは安全に無視できると思います。 2つのフィールドが同じ数を報告し、常に同期していることを確認してください。そうでない場合...まあ...それは実際に問題を意味するかもしれません。