当該 ZFS pool は、mirror 構成で運用しており、1ヵ月に1回のペースで scrub を実行しているのですが、ここ半年間ほど、毎度同じ HDD で ATA bus error が発生し、ZFS mirror のおかげで修復しながら（zpool status の表示が An attempt was made to correct the error. Applications are unaffected. だったので、修復されたものと判断）動いていました。
また、smartctl -A で数値変化を見ていたのですが、Raw_Read_Error_Rate が、scrub のたびに発生する ATA bus error の数だけカウントアップしており、Reallocated_Sector_Ct と Current_Pending_Sector はゼロという推移でした。
このエラーが HDD の不良なのか、はたまた、ケーブル不良や接続不良なのか、まずは切り分け試みようと、別の HDD を接続しているケーブルと交換してみたり、SATA ポートを変更してみたりしました。しかし、やはり当該 HDD のみ scrub で ATA bus error になることが分かりました。
ということから、本当に HDD 不良で間違いないようであり、このまま運用続けた場合、mirror の正常側の HDD が故障すると、データロストに至ると認知しました。
当然、処置としては別の HDD に交換するのが正しいわけで、まずは、用立てた HDD に zpool replace しました。機能は知っていたものの、本当に実行したのは初めての経験でしたが、何事もなく無事完了しました。
さて、エラーが出ていた HDD は、容量 2TB であり、結構もったいない。SecureErase したら、不良部分がリフレッシュするのではという憶測がありましたが、今回は正攻法で、smartctl でテストを行ってみることにしました。
# smartctl -t short /dev/sdXXそうしたところ、LBA_of_first_error が表示され、不良セクタの存在が示されました。本当に、そのセクタにアクセスできないのか確かめるため、次のコマンドを実行してみたら、I/O error になりました。
# dd if=/dev/sdXX of=/dev/null bs=512 skip=＜LBA_of_first_errorの値＞ count=1それならば、当該セクタにゼロ書き込みすれば、修復するかもとやってみました。
# dd if=/dev/zero of=/dev/sdXX bs=512 seek=＜LBA_of_first_errorの値＞ count=1しかし、この書き込みは I/O error で失敗しました。それで思ったのが、この HDD は AFT だし、不良セクタも 4096 バイト単位であるはずなのではということです。確認のため、LBA_of_first_error-1 のセクタを dd で読み出したら、そこは成功。次に、LBA_of_first_error+1〜+7 の範囲のセクタを dd で読み出し試みたところ、全て失敗。さらに LBA_of_first_error+8 のセクタを読み出したら成功しました。推測通りのようであり、512 バイト単位で書き込もうとしても、Read-modify-write 動作となるために失敗するものと考えられました。そこで、次のようにして 4096 バイトを1回で書き込んだところ、サクっと成功しました。
# dd if=/dev/zero of=/dev/sdXX bs=4096 seek=$((3005239984/8)) count=1 ※値はsmartctlが示した本当の値そして、再び smartctl -t short を実行。。。しかし、また別の LBA が表示されました。そのセクタも同様にして 4096 バイト書き込みクリア。。。さらにさらに smartctl -t short を実行。。。また別の LBA が。。。ってなことを繰り返した結果。最終的に、エラーが無くなりました。実際の smartctl の出力は次の通りです。
# smartctl -a /dev/sdXX ... SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 1127 3 Spin_Up_Time 0x0027 238 236 021 Pre-fail Always - 3066 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 69 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 080 080 000 Old_age Always - 14706 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 68 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 20 193 Load_Cycle_Count 0x0032 153 153 000 Old_age Always - 141013 194 Temperature_Celsius 0x0022 111 108 000 Old_age Always - 41 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 14674 - # 2 Short offline Completed: read failure 10% 14674 3005241696 # 3 Short offline Completed: read failure 10% 14674 3005241144 # 4 Short offline Completed: read failure 10% 14674 3005240096 # 5 Short offline Completed: read failure 90% 14674 3005241064 # 6 Short offline Completed: read failure 10% 14674 3005241064 # 7 Short offline Completed: read failure 90% 14674 3005240104 # 8 Short offline Completed: read failure 10% 14673 3005240104 # 9 Short offline Completed: read failure 10% 14673 3005239984 #10 Short offline Completed: read failure 10% 14672 3005241744 #11 Short offline Completed: read failure 90% 14672 3005239984 #12 Short offline Completed without error 00% 8469 - ...このディスクを使い続けるのはリスクだろうとは思いますが、もったいないので、元の ZFS mirror に attach して、三重ミラー化しました。次のような具合です。
# zpool status
...
NAME STATE READ WRITE CKSUM
tankX ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-Hitachi_HUA723020ALA640_xxxxxxxxxxxxxx-part3 ONLINE 0 0 0
ata-WDC_WD20EFRX-68EUZN0_WD-yyyyyyyyyyyy-part3 ONLINE 0 0 0
ata-WDC_WD20NPVT-00Z2TT0_WD-zzzzzzzzzzzz-part3 ONLINE 0 0 0
...
3番目のディスク（WD20NPVT）が不良が生じたディスクで、2番目が交換したディスク（WD20EFRX）です。resilver はエラー無く完了済みで、その後、scrub をかけているところです。scrub でエラーが出なければ、ひとまず不良が消え去ったことになりますが、それは後日、scrub 完了してから追記したいと思います。なにせ、scrub が 24時間 くらいかかるもので。2014-11-05追記
昨日、三重ミラー状態での scrub が完了したのですが、やはり WD20NPVT で、ATA bus error が出ており、smartctl -t short を行ったら、またも、LBA_of_first_error が表示されました。最後の手段、だめもとで SecureErase をかけてリフレッシュを試みました。2TB もの大容量HDDに SecureErase をかけたのは初めてでしたが、やはり実行時間がかなり長く、約6時間40分ほど（84MB/s程度）で無事に完了しました。その直後の smartctl -t short でも、やはり LAB_of_first_error が出ました。これはどうにもダメそうですかね。Reallocated_Sector_Ct がゼロのままだし、何かコマンドで、強制的に代替セクタに切り替えることができれば、まだ延命できるのではと思ってしまいますが。
2014-11-06追記
ダメそう（不良セクタ番号を HDD に通知して、強制的に代替セクタに切り替えるような方法がわからず）なので、三重ミラーから detach して、別の zpool を作って、copies=2 設定で利用しようかと思います。これ、話しには聞くものの、やったことの無い設定なので、実験のためにデータを充填中（コピー中）。プールの使用率が 80% 程度になったら、scrub をかけてみて、ATA bus error になっても、修復動作が動くのかどうか実験してみるつもりです。。。ただ、copies=2 のプールへの書き込みはさすがに激オソ（10MB/sくらい）になるようです。シーケンシャル READ なら 90MB/s くらいは出るようなので、iso イメージ格納とかなら、使用に耐えるものと考えられます。
2014-11-11追記
copies=2 のプールへの実験的書き込みが終わった（使用率 78%）ので、今度は scrub を実行中ですが、その前に、別のメンテで、そのサーバをシャットダウンしたのですが、そうしたところ WD20NPVT にアクセスできなくなって（device error になって）焦りました。一瞬、ぶっ壊れたのかと思ったのですが、以前にも経験したことがあるのですが、SecureErase を行った副作用で、HDD がロック状態になってしまったようでした。
# hdparm -I /dev/sdXX
...
Security:
...
enabled
locked
not frozen
...
上のような状態になってしまっていました。解除方法は、次の通りです。
# hdparm --user-master u --security-unlock password /dev/sdXX # hdparm --user-master u --security-disable password /dev/sdXXこの処置で、再びディスクにアクセス可能になり、scrub 実行中です。それにしても、SecureErase を行ってもロックされない HDD もあり、製品により挙動はまちまちのようです。
2014-11-12追記
さらに続きのメモですが、scrub が完了し、やっぱり途中で ATA bus error が出ているものの、zpool status では repaired だったので、copies=2 で救われたものと判断しました。その後、書き込んだデータ（実験のため Fedora/CentOS などの iso イメージを書き込みました）の md5sum チェックを行いましたが、途中でやはり ATA bus error が出たものの、md5sum 値は全て OK でした。というわけで、iso イメージ格納庫にしようかなと思案中。
2014-11-15追記
その後、書き込んだ iso イメージの md5sum チェックを何回か行いましたが、結果は全て正常値でしたので、このまま iso イメージ倉庫にしようかと思います。
その他の延命利用方法としては、今のところ ATA bus error が出るセクタ番号範囲が狭い（サイズにすると 1MB くらいの領域）ので、その部分だけ小さいパーティションで区切り、その他の正常なパーティションを md の linear モードで連結して使うという方法が考えられると思います。あるいは、LVM の運用がイヤでなければ、正常なパーティションを１つの VG にして使う方法もありそうです。
■関連記事
中古 HDD の初期確認
0 件のコメント:
コメントを投稿