新規購入したHDDの初期不良のチェックやRAIDアレイの再構成が一段落ついたので、 先日故障が発覚したHDD(Seagate Barracuda 3.5, ST3000DM008-2DM166)で遊んでみたいと思います。
とにかくドライブのサイズがそれなりに大きいので、一つのコマンドの結果が返ってくるまでに5時間など当たり前なので、一日一コマンドづつしか入力できないのがもどかしいのですが、まあ折角ですので、これまで何度もやっているとはいえ、訓練を重ねることは悪いことではありません。
今回はまず、不良セクタを何とかしたいと思います。
今回の状況としては、/dev/sddとして接続し、ext4の単体ドライブとしてmkfs.ext4をしなおしたうえでrsyncコマンドで元のRAIDの内容をコピーしてある状況を作りました。
まずは異常セクタの特定から行いたいのですが、前回書いた通り、smartctl -t longテストでは異常なしとか平気で言い放つ始末で手に負えません。
実際には以下のパラメータが48まで上昇しているにもかかわらず、です。
・197 Current_Pending_Sector
・198 Offline_Uncorrectable
もはやHDDの自己テスト機能がダメになっているのかもしれません。
そこで、badblocksコマンドを用いて異常セクタを検出したいと思います。
まあ、念のため、再度ブロックサイズを確認します。
1 2 | # tune2fs -l /dev/sdd1|grep -i "block size"Block size: 4096 |
このパラメータをbadblocksに与えて検査させます。
1 2 3 4 | # nohup badblocks -b 4096 -vs -o badblocks.txt /dev/sdd1&tail -f nohup.outChecking blocks 0 to 732566271100.00% done, 5:23:20 elapsed. (139/0/0 errors) |
ということで、五時間半かかって、139セクタもの不良セクタが検出されてしまいました。
この段階でのsmart値は以下の通りです。
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 | ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 097 093 006 Pre-fail Always - 40328485 3 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 49566908 9 Power_On_Hours 0x0032 063 063 000 Old_age Always - 32571 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 6183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 262188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0189 High_Fly_Writes 0x003a 099 099 000 Old_age Always - 1190 Airflow_Temperature_Cel 0x0022 076 060 045 Old_age Always - 24 (Min/Max 20/26)191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 4193 Load_Cycle_Count 0x0032 073 073 000 Old_age Always - 55928194 Temperature_Celsius 0x0022 024 040 000 Old_age Always - 24 (0 13 0 0 0)197 Current_Pending_Sector 0x0012 094 094 000 Old_age Always - 1112198 Offline_Uncorrectable 0x0010 094 094 000 Old_age Offline - 1112199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 32556h+15m+05.395s241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 25786278431242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 1151768457351 |
いやあ、すげえ。Current_Pending_Sector とOffline_Uncorrectable が1112にまで上昇してしまいました。
これから試す方法の挙動が楽しみです。
さて、まずは実際にbadblocksコマンドで得たセクタ番号がHDD自身から聞けるかどうか、smartctl -t shortで尋ねてみました。
1 2 | # 1 Short offline Completed: read failure 90% 32571 -# 2 Extended offline Completed without error 00% 32452 - |
全然教えてくれる気はないようです。
しかし、前回、異常が発生しているにもかかわらずエラーなし(#2です)で正常終了していたのが、read failureで異常終了(#1です)しているのはせめてもの事でした。
異常なしっていう時点でおかしいですもの。
まあ、HDDが異常セクタを教えてくれないとのことですので、それならばbadblocksで検出した139の異常セクタをどうにかすればsmart値はどうなるのかを見ていきたいと思います。
その前に、異常セクタにあるファイルを削除するため、先ほどのbadblocksコマンドで生成された badblocks.txt に記録されているセクタ番号をもとに、debugfsコマンドでセクタ番号から使用されているinode番号を取得して、そのinode番号をもとにファイル名を特定します。
無論、すぐに廃棄する予定のHDDでここまでする必要はないのですが、せっかくの演習ですから壊れても惜しくない大容量HDD(いや、もう壊れているのですが)、有効活用してみたいと思います。
まずは指定したセクタに何らかのデータが記録されているかを調べるには以下です。
セクタ番号が524726232として、icheck <セクタ番号>で調査します。
1 2 3 4 | # debugfs -R "icheck 524726232" /dev/sdd1debugfs 1.42.9 (28-Dec-2013)Block Inode number524726232 117966080 |
ばっちり使われています。
使われていない場合は次のような表示になります。
1 2 3 4 | # debugfs -R "icheck 620236906" /dev/sdd1debugfs 1.42.9 (28-Dec-2013)Block Inode number620236906 <block not found> |
これを139セクタ分繰り返します。
ファイル名を得るには
1 | # debugfs -R "ncheck 117966080" /dev/sdd1 |
というように、"ncheck inode番号" を実行しますと、ファイル名が表示されます。
inode番号は重複する場合がありますので、sortしてuniqしたほうがいいと思います。
数が数ですので、awkなりperlなりpythonなり、スクリプトを書いたほうが安全かと思います。
さて、今回のケースではファイル数に換算すると46ファイルでした。
でかいファイルが配置されていたセクタが多かったようです。
早速それらをunlinkして、smart値を見てみますと、特に意味がある変化は見られません。
当たり前といえば当たり前ですが。
お次はddコマンドで0を書き込んでセクタを代替させる作業を行います。
139セクタすべてを0で埋めますが、その前に1セクタだけやって、smart値がどう変化するかを見てみたいと思います。
1 2 3 4 5 6 7 8 9 10 11 12 13 | # dd if=/dev/zero of=/dev/sdd1 bs=4096 count=1 seek=5247262321+0 レコード入力1+0 レコード出力4096 バイト (4.1 kB) コピーされました、 0.00141101 秒、 2.9 MB/秒# sync# smartctl -a /dev/sdd1ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE (略) 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8 (略)197 Current_Pending_Sector 0x0012 094 094 000 Old_age Always - 1104198 Offline_Uncorrectable 0x0010 094 094 000 Old_age Offline - 1104 (略) |
おやおや、Reallocated_Sector_Ct の値は変化がありませんが、Current_Pending_Sector とOffline_Uncorrectable の値が2ポイント増えてしまいました。なかなか興味深い事象なので後で遊ぶとして、あと138セクタあるので、残りは一括してスクリプトを組んでゼロで埋めてしまいます。
その結果、
1 2 3 | 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8197 Current_Pending_Sector 0x0012 100 094 000 Old_age Always - 0198 Offline_Uncorrectable 0x0010 100 094 000 Old_age Offline - 0 |
Current_Pending_Sector とOffline_Uncorrectable の値がゼロになり、代替されたセクタが増えていません。
これ、書き込みが成功した場合は代替しないっていうHDDがあることは知っていましたが、このHDDもその一味なのでしょうか。
念のため、これらのセクタを下手に使ってしまわないようにファイルシステムに"コイツはダメだ"と記録しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | # fsck.ext4 -l badblocks.txt /dev/sdd1e2fsck 1.42.9 (28-Dec-2013)/dev/sdd1: Updating bad block inode.Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structurePass 3: Checking directory connectivityPass 4: Checking reference countsPass 5: Checking group summary informationFree blocks count wrong for group #18928 (23698, counted=23699).Fix<y>? yesFree blocks count wrong for group #19312 (24543, counted=24544).Fix<y>? yesFree blocks count wrong for group #20416 (24543, counted=24544).Fix<y>? yesFree blocks count wrong for group #22000 (24543, counted=24544).Fix<y>? yesFree blocks count wrong for group #22032 (24542, counted=24544).Fix<y>? yesFree blocks count wrong (63487139, counted=63487145).Fix<y>? yes/dev/sdd1: ***** FILE SYSTEM WAS MODIFIED *****/dev/sdd1: 97313/183148544 files (1.5% non-contiguous), 669079127/732566272 blocks |
ま、結果は信用できませんが、仕上げに自己テストを行わせます。
1 | # smartctl -t long /dev/sdd |
結果は後日のお楽しみです。(どうせwithout errorでしょうねぇ)
それにしても、3TBという容量が容量なので、こんな危なっかしいHDDをだましだまし使うということは難しい感じです。
廃棄以外にちょっと考えられません。
6TBとか8TBとかがボリュームゾーンになってきている様子ですが、今後ますますトラブル発生即交換・廃棄という運用じゃないととてもやっていけませんねえ。
貧乏性にはつらい選択です。
結果として、頓死しないでずるずる生き延びる、なんだかおもしろい機材が手に入ってしまったので、今後も時間があれば何らかのネタを仕込んでみたい気もしますが、まずは来月あたりにもう一度badblocksコマンドで総なめしてみて、何か面白いことが起きるかどうかですかねえ。
まずは今回はこんなところでしょうか。
ここまでお読みいただき、ありがとうございました。
0 件のコメント:
コメントを投稿