48TBファイルサーバに起こった異変から大修理に(3) 再同期完了編(交換2台目)

今回の話はそこまで怖い話ではなく、単に流れをみているだけです。

 

8番目の交換が完了した時点で3番目のHDDはどうなっていたのか?

SMARTの出力で主要な部分だけ書くとこんな感じです。

…
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       112
…
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
…
ATA Error Count: 2
…
Error 2 occurred at disk power-on lifetime: 11521 hours (480 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 53 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 58 ff ff ff 4f 00      00:06:58.915  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.913  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.913  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00      00:06:58.909  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.908  READ FPDMA QUEUED
…

SMARTの状態を知っている人ならわかると思いますが、Reallocated Sector Countが出ている時点ですでに危険な状態です。とりあえず予備のSectorでカバーできているけれども使えないSectorが出始めている、という意味です。これが行き過ぎると不良セクタが発生してデータ破損につながります。なので、もうこれは交換しないと近々故障することが確定しているディスクとなります。しかも、Read Errorについてもこちらに報告されているということはその意味でも故障寸前ということが推察されます。ちなみに、この修復作業をする前はReallcated Sector Countは数十セクタほどで、Read Errorに関する報告もSMARTからは出ていなかったので、resilver作業によってかなり危険度が増していることになります。

 

今回の交換はそれほど難しくはない

というのも、前回の話のせいで何回もresilver処理を行っている(この場合はscrub処理に近い処理を行った、という意味も含まれる)ため、ZFS側のファイル破損の可能性はほとんどない状態ということで、ZFSにおけるストレージ1つ分の交換処理だけですむからです。これに関しては本当にこちらの記事を読めばOKです。HDDの場所もしっかり確認しているためその手の問題はありませんでした。

 

修理するために使った金額はいくら?

結局交換用SATAインタフェースカード(SATA3-6I-PCIE×2)+故障したHDDの交換分(2台分)ということになります。約5万円ですか。ちょっとした出費となり痛かったです。

 

破損したファイルはほかにあったのか?

なんとか初期に発覚した1つだけで済んだようです。といっても破損したファイルのデータは全く戻ってこないので痛いですね。なお、ZFSの領域は私の設定だと圧縮領域なので途中でデータ破損がすればまず間違いなく破損部分以降の読み出しは不可能で、アーカイブファイルにリカバリレコードをつけることで…とかは全く意味がなかったことも付け加えておきましょう。圧縮領域でなければ読み出せたのか?といわれるとおそらく無理、となるのでしょうが。

 

こうならないように故障の前兆はつかむようにしましょう

今回はSATAインタフェースカードとHDDの同時故障が原因だったのでなかなか難しいところではありますが…。SATAインタフェースカードの場合はdmesgなどでI/Oエラーが出ていないか?がチェックの対象になりますし、そうでなかったとしてもzpool statusから見ることができるエラー状況は「なぜ起こったのか」をSMARTやdmesgなどである程度理由をつかんでおかないといかにRAID-Z2といえども危ない状況になることはある、というのが今回の教訓ですね。つまりは定期的にPCの状態は確認して管理しましょう、というところですか。あとはzpoolの修復も途中のエラーによってはやり方を変えないといつまでたっても終わらない、ということがわかってよかったです。日本語の記事でこれに言及しているものがほとんどなく、英語の記事でも詳細なものはほとんどない様子でしたので。もしzpoolの修復の話でこの記事にたどり着いた人は前回修復手順を参考にしてみてください。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

この記事のトラックバック用URL