3年6か月目にST3000DM008に異常発生、WD40EZRZ-RT2購入

一昨日、自宅サーバにて二台のST3000DM008でRAID1を構成していた一台に異常が発生していることが発覚しました。

ペアを組んでいるもう一台のST3000DM008は何の問題もなく元気に稼働しています。

異常は毎週のraid-checkで検出されていました。

よくよく調べてみると、先月のsyslogにすでに異常が報告されていることが分かりました。

smartctlからもmdadmからもメールが来なかったのですっかり油断していました。

2017年6月に運用を開始して以来、メーカーが保証していない24時間365日な自宅サーバ上での使用でこれだけの期間、頑張ってくれたことに感謝です。

実際のところ、ST3000DM001の型番だけ変更品なんじゃないかという疑念が付きまとっていた本製品だけに、一層感謝の念が深まります。

障害の内容は、syslogによるとアクセス不能なセクタが発見されていました。

1 2 3 4 5 6 7 8 9 10 11 12 13

Mar  7 05:57:53 ***** kernel: ata3.00: exception Emask 0x0 SAct 0x100000 SErr 0x0 action 0x0 Mar  7 05:57:53 ***** kernel: ata3.00: irq_stat 0x40000008 Mar  7 05:57:53 ***** kernel: ata3.00: failed command: READ FPDMA QUEUED Mar  7 05:57:53 ***** kernel: ata3.00: cmd 60/00:a0:00:17:46/01:00:45:01:00/40 tag 20 ncq 131072 in#012         res 41/40:00:38:17:46/00:01:45:01:00/00 Emask 0x409 (media error) <f> Mar  7 05:57:53 ***** kernel: ata3.00: status: { DRDY ERR } Mar  7 05:57:53 ***** kernel: ata3.00: error: { UNC } Mar  7 05:57:53 ***** kernel: ata3.00: configured for UDMA/133 Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Sense Key : Medium Error [current] [descriptor] Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Add. Sense: Unrecovered read error - auto reallocate failed Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 CDB: Read(16) 88 00 00 00 00 01 45 46 17 00 00 00 01 00 00 00 Mar  7 05:57:53 ***** kernel: blk_update_request: I/O error, dev sdc, sector 5457188664 Mar  7 05:57:53 ***** kernel: ata3: EH complete

驚いてsmartctlで確認したところ、SMART Error Log Version: 1には既に109件もエラーが記録されており、かつ、Reallocated_Sector_Ctの値が8になっていました。

SMART Error Logはこんな感じでした。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

SMART Error Log Version: 1 ATA Error Count: 109 (device log contains only the most recent five errors)         CR = Command Register [HEX]         FR = Features Register [HEX]         SC = Sector Count Register [HEX]         SN = Sector Number Register [HEX]         CL = Cylinder Low Register [HEX]         CH = Cylinder High Register [HEX]         DH = Device/Head Register [HEX]         DC = Device Command Register [HEX]         ER = Error register [HEX]         ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days.   Error 109 occurred at disk power-on lifetime: 32432 hours (1351 days + 8 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 51 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 00 ff ff ff 4f 00  19d+18:25:46.787  READ FPDMA QUEUED   60 00 00 ff ff ff 4f 00  19d+18:25:46.754  READ FPDMA QUEUED   60 00 00 ff ff ff 4f 00  19d+18:25:46.143  READ FPDMA QUEUED   60 00 00 ff ff ff 4f 00  19d+18:25:46.015  READ FPDMA QUEUED   60 00 00 ff ff ff 4f 00  19d+18:25:46.014  READ FPDMA QUEUED

しかしながら、

1	SMART overall-health self-assessment test result: PASSED

なのでsmartctlはメールを飛ばさなかったようです。

ついでにセルフテストを行ってみましたが、こちらも

1	1  Extended offline    Completed without error       00%     32452         -

といわれてしまい、成功終了してしまいました。

兎にも角にも、RAIDが縮退運転に入る前に気づけたことは幸いでした。

早速、気づいたその日にすぐに代替用HDDの選定に入りましたが、最近の手ごろな価格のHDDってほとんどが瓦磁気記録方式(以下SMR)なのでびっくりしました。

確かに、SMRの普及が進んでいるとは噂程度には聞き及んでいたのですが、ちょっと考えてしまいました。

SMRと一言で言っても、大抵はHDDの外周部分をCMRとして使って、あとでゆっくりSMR方式の内周部分に移動する方式が主流のようです。

そのため、毎週テラバイト単位(ベアドライブ単位で丸ごとだから)でのバックアップの処理のパフォーマンスが極端に低下する(CMRとして記録できる領域を超えてしまうため)懸念を抱きました。

また、CMRとして利用するシリンダを酷使することによる耐久性はどうなのかというのも、もう少々、できれば数年、様子を見たいところです。

また、gitでのソース管理などでも、細かいファイルが大量に発生してしまうのですが、これの処理のパフォーマンスも気になります。

まあ、所詮は自宅サーバですし、あまり気にしても仕方がないのですが、面倒になったのでとにかくCMRの製品にしようと思って探してみました。

もともと3TBのHDDだったので3TB近辺で探すと、現在は4TBがお安いようですね。

そのため、1TBはRAIDとしては使えませんが4TBのHDDを探してみると、あっさりWD40EZRZ-RT2という製品が見つかりました。これはCMRなんだそうです。

お値段は8千円。SMR方式の同容量のHDDと比べても最大でも千円前後しか価格差はないようです。

今回異常を示したHDDの先々代がWDでしたが、二年も持たず故障したので、若干気がかりですが、これは我ながら難癖でしょう。

結局のところこういうのはどのメーカでも同じことですし、そもそもメーカが保証しない連続運用が前提な使い方をする以上、すべては自己責任です。

さっそく注文して取り寄せました。

とりあえず例によってmdadmでraid1アレイから故障したHDDをfailさせてremoveします。

(たとえばこんな感じです。sdcが今回壊れたHDDです)。

1 2	mdadm --manage /dev/md0 --fail /dev/sdc1 mdadm --manage /dev/md0 --remove /dev/sdc1

その後、障害が発生したHDDをサーバから物理的に抜去するか、そのまま接続するなら別RAIDに仮参加させるなど元のRAIDアレイに戻らないように工夫した後、 新規購入したHDDのパーティションを元のRAIDアレイのサイズと同じサイズで切って追加します。

パーティションを切る際、partedで開始位置と終了位置をセクタ単位で指定したい場合はセクタ番号の後ろにsをつければ問題ありません。partedでprintコマンドでセクタ単位で表示させたい場合は、

(parted) unit s

とすると表示できます。

もっとも、fdisk -l で事前に見ておいたほうが楽だと思います。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# parted /dev/sdc (parted) mklabel gpt (parted) mkpart パーティションの名前?  []? SDC1-WD4T ファイルシステムの種類?  [ext2]? xfs 開始? 2048s 終了? 5860532223s (parted) set 1 raid on (parted) p モデル: ATA WDC WD40EZRZ-22G (scsi) ディスク /dev/sdc: 4001GB セクタサイズ (論理/物理): 512B/4096B パーティションテーブル: gpt ディスクフラグ:   番号  開始    終了    サイズ  ファイルシステム  名前       フラグ  1    1049kB  3001GB  3001GB                    SDC1-WD4T  raid

その後、partedで余った1TBのパーティションも追加します。

これは正確な数値である必要はないので、開始位置をサイズ、終了位置を100%といったようなアバウトな指定で十分です。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

(parted) mkpart パーティションの名前?  []? SDC2-WD4T ファイルシステムの種類?  [ext2]? xfs 開始? 3001GB 終了? 100% (parted) p モデル: ATA WDC WD40EZRZ-22G (scsi) ディスク /dev/sdc: 4001GB セクタサイズ (論理/物理): 512B/4096B パーティションテーブル: gpt ディスクフラグ:   番号  開始    終了    サイズ  ファイルシステム  名前       フラグ  1    1049kB  3001GB  3001GB                    SDC1-WD4T  raid  2    3001GB  4001GB  1000GB                    SDC2-WD4T

余談ですが、もちろん、こんなアバウトな指定のしかたでも、きっちりパーティション2はパーティション1の次のセクタから確保されています(unit sしてprintすればわかります)。

こういった地味だけどとても便利で親切なコマンドを作る気配りというのは、下手をすると余計なお世話になってしまうために目には見えないけれど実際には相当負担が大きいのですが、それをあえてするプログラマの心意気に頭が下がります。

そして、上記で生成したパーティションをアレイに追加すればリカバリが始まります。

1	# mdadm --add /dev/md0 /dev/sdc1

今回のリカバリは夜の20時30分に開始して翌未明02時16分に完了しました。

六時間弱、かあ。するとリカバリ速度は約141,963KB/秒ですね。

ただ・・・容量違いのHDDでRAID1を組むと、新しくて、しかも大きい容量のHDDのほうが先に壊れた経験があるので、今回は先例通りにならないことを願うばかりです。

余談ですが、容量が大きいHDDが先に死んでしまったときに生き残ったHDD(ST31000528AS)は2009/04/24から現在まで元気に活躍していました。

彼の初代の相棒はWD10EADS-00L5B1(2009/04/24運用開始、2011/03/吉日死亡)、次の相棒がST2000DL003(2011/3/22運用開始、2017/06/21死亡)でした。

その後、二代目の相棒の死亡を機にRAIDアレイを引退。

余生をPCクライアントのバックアップ置き場として活躍するものの、2021年3月10日、容量の小ささと古さから廃棄処分となりました。

こちらも、本当によく働いてくれました。

ご苦労様でした。ありがとうございました。

あとは自己診断の結果待ちですが、45,180秒かかるそうなので、初期不良の判定はもうちょっと先になりそうです。

さらに故障が判明してから停止していたrsyncによるraidアレイのバックアップ先との同期やらがあるので当分先の話になりますが、hdparmやddコマンドを用いての単体のHDDの転送速度の実測とか負荷がかかる試験をいろいろ試したいのですが、徐々に進めたいと思います。

ネタのつもりで買ったST3000DM008がここまでしてくれたので、ちょっとうれしくて思わずこのような駄文をひねくってしまいました。

お読みいただきありがとうございました。

---

2021/03/11 追記

異常が発生したST3000DM008をmkfsしなおして、rsyncコマンドでraid1の中身を全コピーしてみたところ、何の異常もなく終了してしまいました。結果は以下の通りです。

1 2	sent 2.80T bytes  received 1.69M bytes  139.56M bytes/sec total size is 2.81T  speedup is 1.00

RAID1のリカバリ時間とほぼ同等ですかね。おおよそ五時間半かかりました。

それにしても、何の異常もなく正常終了してしまうのには困りました・・・

dmesgにもmessagesにもsmartdctl -aの結果にも、まるで何も記録されていません。

RAIDのアレイ構成員としては恐ろしいのでスペアに指定することなんか想像もできませんが、それはさておいて、3TBもの領域でどう遊んでいいやら。

貧乏性の悩みは尽きませんが、かといって、なんらかのネタを思いつければいいのですが・・・