ハードドライブの読み取りエラー...停止しますか？

私の話は非常に単純に始まります。Arch Linuxを実行する軽量サーバーがあり、そのほとんどのデータを2つのSATAドライブで構成されるRAID-1に保存しています。約4ヶ月間問題なく動作していました。その後、突然、ドライブの1つで読み取りエラーが発生し始めました。常に、メッセージは次のようになりました。

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

エラーごとに異なるセクター番号が表示され、ディスクにアクセスするユーザー（私）の数秒の遅延が発生しました。

smartctlの出力を確認したところ、次の出力が確認されました（無関係な部分はクリップされています）。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

ログを振り返ってみると、エラーは実際には数日間、主にバックアップ中に発生していましたが、非常に軽い使用中にも頻繁に発生していました（つまり、テキストファイルを保存しようとする5回おきに）。私のディスクは故障しており、RAID-1はそれを適切に処理しており、交換用ディスクを注文する時がきたと結論付けました。新しいディスクを注文しました。

驚いたことに、1日後、エラーが...停止しました。私はそれらを修正するために何もしませんでした。再起動したことも、ドライブをオフラインにしたこともありませんでした。しかし、エラーは停止しました。

その時点で、不良セクターがディスクのアイドル部分にあるかどうかを知りたくて、ディスクをRAIDから取り出し、RAIDに戻し、その後の完全な再同期を完了させました。9時間後、エラーなしで再同期が完了しました（2 TBのディスクには少し時間がかかります）。

また、smartctlの出力は次のように少し変更されています。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

ですから、私にとって奇妙なのは、もちろん「不良ディスクはいつ修復されるのですか」ということです。

ドライブの非常に小さな領域が自発的に不良になり、ドライブがセクター再割り当てコードが起動してディスクの不良領域にいくつかのスペアセクターをマッピングするまでに3日（！）かかった可能性があると思います...しかし、私は今までにそのようなことが起こるのを見たとは言えません。

他の誰かがこの種の行動を見たことがありますか？もしそうなら、その後のドライブ体験はどうでしたか？再び起こりましたか？ディスクは最終的に完全に故障しましたか？それとも、説明されないままになっている説明されていないグリッチだけでしたか？

私の場合、交換用ドライブを既に持っています（保証期間中に取得）ので、とにかくドライブを交換するだけです。しかし、私はこれをどういうわけか誤診したかどうか知りたいです。それが役立つ場合は、問題が発生したときからの完全な「smartctl -a」出力があります。ちょっと長いのでここには投稿しませんでした。

ドライブサーフェスの1つの特定の物理領域が不良になると、それらのセクターが正常にマップされるまで、その領域に書き込まれたデータを読み取ろうとすると、回復不能な読み取りエラーが発生します。ドライブはセクターが不良であることを認識しています（セクターへのアクセスに失敗した後）が、すでにデータを保持しているため、セクターを再マップできません。ドライブをフォーマットするか、「不良」セクターを上書きすると、ドライブに不良セクターをマッピングする機会が与えられます。

不良セクターがマップされ、ドライブサーフェスの多くが故障しない限り、問題はありません。

現在のドライブのドライブ障害モデルについて、メディア表面の一部が不良になることと、問題が拡大または再発することとの間に多くの相関関係があるかどうかを知るには十分な知識がありません。相関関係がない場合、不良セクターがマッピングされると、良好な状態になります。そこにいる場合で相関が、これは、ドライブのための終わりの始まりです。

最近のほとんどのドライブは、不良になったブロックを「ベクター化」します。ドライブにはスペアブロックのプールがあり、ファームウェアはこれらを使用して、ドライブが不良であると認識しているブロックを置き換えます。ドライブは、正しいデータを提供できないため、ブロックの読み取りに失敗すると、この再マッピングを実行できません。「読み取りエラー」を返すだけです。これは、ブロックを不良としてマークするため、ブロックが正しく読み取られた場合、ブロックはベクトル化され、正しいデータが置換ブロックに書き込まれます。OSが「ベクターアウトペンディング」状態のブロックに書き込む場合、そのブロックはベクターアウトされ、データは代替ブロックに書き込まれます。

Linuxソフトウェアraidは、デバイスから読み取りエラーを取得すると、配列内の他の要素から正しいデータを取得し、不良ブロックへの書き込みを再試行します。SO、書き込みが正常に機能する場合、データは安全です。安全でない場合、ドライブは上記の処理を行い、ブロックをベクトル化してから書き込みを実行します。つまり、ドライブはraidシステムの助けを借りて、それ自体を修復しました！

そのようなイベントがかなりまれであると仮定すると、おそらく続行しても安全です。交換ブロックが多すぎる場合は、ドライブに問題がある可能性があります。スペアブロックにベクター化できる置換ブロックの数には制限があり、これはドライブの機能です。

はい、これも同様の状況で見ました。私の場合、そのスタントを引っ張ったのは「コンシューマーグレード」のWestern Digital 1TB「グリーン」ドライブ（WD10EARS）でした。SMARTのCurrent_Pending_Sectorraw値が0から6になり、次に8になり、SMART監視デーモンに不吉な電子メールをいくつか送信するように促しました。

私はmdadm --failエドと--remove、アレイからドライブをD、および非破壊パスを走ったbadblocksその上に、はい、以上2ダースの不良ブロックが明らかにありました。交換用ドライブが約1日後に到着したとき、私はアレイを修正し、寿命は続いた。

その後まもなく、退屈な状態から抜け出しbadblocks、「失敗した」ドライブを再実行して、悪化したかどうかを確認しました。それどころか、ドライブは完全に「修復」されました。不良ブロックはゼロです！首を振って、拭いてリサイクルするか寄付するために取っておきました。

教訓：あらゆる種類の奇妙さと信頼性に我慢して耐えられるのでない限り、サーバーでコンシューマーグレードのドライブを使用しないでください。当然の結果：サーバーコンポーネントを安く購入しないでください。いずれにせよ、結局、余分な時間と煩わしさでそれらの費用を支払うことになります。

サーバー環境では、このようなエラーが発生したことがあるドライブを、修正するかどうかにかかわらず破棄することが一般的です。セクターのハードエラーは、媒体への物理的な表面損傷の兆候である可能性があります。表面に傷を付けると、通常、材料を傷の側面に移動して、そのような表面の平面よりも高いバリまたは研磨粉（ガラス！ ）。どちらも、2つの表面の間の非常に薄いエアクッションが完全に滑らかであると想定される機械システムにかなりダメージを与える傾向があります。そのため、特定のカウントに達し始めると、中程度のエラーが急増する傾向があります。