SSD MSI S270 960GB における smartmontools から見える Total_LBAs_Written の単位はいったい何なのか?

 サーバ(Linux)のシステムとホームディレクトリのパーティション用に購入したSSD、MSI S270 960GB。5年保証付きなのに激安でした。

購入してから2806時間を経過したので、そろそろTBWが気になるお年頃です。

早速smartmontoolsでもって累計書き込み時間を見てみました。

smartctl -A の結果は

ID# ATTRIBUTE_NAME          FLAG     (略) RAW_VALUE
  9 Power_On_Hours          0x0012   (略) 2806
                    （略)
241 Total_LBAs_Written      0x0012   (略) 467

467ってなんじゃい!!

RAW VALUEは生値ってくらいなのでメーカー毎にまちまちです。smartmontoolsを使う際の単位不明あるあるケースですね。

ということで単位が何なのか調べてみました。

といってもたいしてやることはありませんでした。

smartctl -l devstat で見てみると

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  0x010  4            2806  ---  Power-on Hours
                  (略)
0x01  0x018  6       981352770  ---  Logical Sectors Written
0x01  0x028  6      4076567750  ---  Logical Sectors Read

しっかりと論理セクタ書き込み回数が取得できましたので、論理セクタサイズは smartctl -a で取得すると512バイトということだったので、

981352770 * 512 ÷ 1024 ÷ 1024 ÷ 1024 = 467.9... となりました。

従いまして、MSI S270におけるTotal_LBAs_Writtenは、LBAsとはありますが実際には単純に「書き込み済み総ギガバイト数」でした。

いや、GiBだからギビバイトというべきでしょうか。

面白いですね。ストレージの容量はGB(1,000,000,000)単位なのに書き込みデータ量はGiB(1,073,741,824)単位なんですねえ。

だから何だといわれても困るのですが。。。営業と技術の部門間の考え方の乖離が垣間見える気がします。

個人的には20世紀から連綿と狂ったようにストレージへの書き込みアクセスを抑止するために最悪でもtmpfsを無理やり利用するなど散々苦労してきたことがここで目に見えて感無量です。

以上、ここまでお読みいただいてありがとうございました。

Western Digital WD60EZAX の IntelliPark (idle3) のタイムアウト値

 まず結論から申し上げます。10秒でした。

以上です。

以下たわごとです。

過日、12年物の東芝のD01ACA200が突然死してしまいました。よく頑張ってくれました。

そこで、代替を物色したところ、一時期に比べて価格が大幅に上がっていて驚きました。いろいろ検討しましたが、IntelliParkが切れないと評判の一品、WD60EZAX が\14,500円だったので、故障した玉とは別に予防交換用として1玉、併せて2玉購入しました。モデル名とファームウェアのバージョンは両者ともに次の通りです。

Device Model:     WDC WD60EZAX-00C8VB0
Firmware Version: 01.01A01

さっそくエージングを行うのと並行して、実際にidle3タイマの値を取得・変更できないか試してみました。

1 2	# idle3ctl -g /dev/sdb sg16(VSC_SENDKEY) failed: Input/output error

とのことなので、値すら取れず、駄目でした。なお、idle3タイマを切れる別のWD40EZRZ (ちなみにLoad_Cycle_Countが29,441時間で534,518回) という玉で idle3ctl コマンドの有効性を確認しております。

※Load_Cycle_CountはWindowsで普及しているCrystalDiskInfoでは"ロード/アンロードサイクル回数"と表記されていますので適宜読み替えてください。

で、今回調達したWD60EZAXのうち、よく編集するファイルなどが配置されるドライブに1玉割り当ててみました。そのほうはたった24時間でLoad_Cycle_Countが140回を超えました。ファイルを編集しながらこまめにセーブするだけでどんどんLoad_Cycle_Countが上がってゆくイメージです。こういった使い方だと保証期間が2年とすると17,520時間なので、245,000回となりますので、保証期間内では問題なさそうです。

で、ついでに作業の合間にidle3のタイマー値を実測してみました。方法は次のようなスクリプトを一定時間流してLoad_Cycle_Countの値を見てみるという原始的なものです。

1 2 3 4 5 6 7

#!/bin/sh while :; do         smartctl -a /dev/sdb | grep Load_Cycle_Count         #sleep 7 # OK         sleep 9 # OK         # sleep 11 # NG done

結果は9秒毎にS.M.A.R.T.情報を取得した場合は増加しませんが、11秒毎だと増加が認められましたので10秒と判断した次第です。

もうひと玉は別OS下で LibreHardwaraMonitor が一秒毎に情報を更新している環境下での利用のため、つまりS.M.A.R.T.値を取得するために毎秒アクセスされるので、IntelliParkの出番はなさそうです。

以上、たわごとでした。

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

ケーブル一つでもシステムにとってかけがえのない存在なことを再認識させられました

 現在使っているPCは、かれこれ足掛け10年の間、週一回程度にビデオカードの差し直しをしないと正常に使えなくなるという爆弾を抱えているものの、ハードウェア的には仮に起きても本当に些細なトラブルばかりで（PT3が壊れた!と思ったら差し直したら直ったとか、20年以上愛用のPS/2キーボードの右CTRLキーがついに押下すると元に戻らなくなったりとか、そんなのばっかりで)びっくりするほど安定(VGAから目を背けつつ)しているのですが、やっとネタになりそうなハードウェアトラブルが発生したので記録する次第です。

まず、HDDのGドライブとして運用中の、このPCの他のハードディスクの中身をバックアップするだけの用途のドライブがあると思ってください。

そのGドライブが、ある日、アクセスされっぱなしになっていることに気づきました。

バックアップ専用ドライブですから、バックアップ中以外にBUSYになっている時点でおかしいのですが、実際にＧドライブにエクスプローラーからアクセスしてみると妙に遲いものの各ファイルには正常にアクセスできます。

とりあえず、Windowsにおける最強のトラブル解決手段であるところのリブートを行ってみました。すると、特に問題なさそうな様子をしています。

しかし、実際には何か異常が起きたからこそ奇妙な挙動をしたのですから、原因を知りたい。

そこで、これは10年近い年季のHDDがいかれかけでバッドセクタが出たのかな?と考えてSMART値をチェックしてみました。しかし、SMARTを軽く見てみても、代替処理済みのセクタ数もセクタ代替処理保留中のセクタ数も回復不可能セクタ数もゼロのままで問題がなさそうです。

そこで、念のため chkdsk /r G: をかけてバッドセクタを探させることにしました。

すると、ステージ４である程度の個所でディスクへのアクセス頻度は高いけれど進捗がぱったりと進まなくなる状況になりました。

この辺は場数をどの程度踏んでいるかによるのですが、大容量HDDだから進捗が進まないのか、トラブルが起きているから進まないのかの見極めが必要となります。
ここでは後者、何らかのトラブルが発生しているためにchkdsk が進まないと判断して中断させようとしましたが、CTRL+CもCTRL+Breakも効果なく、やむなくコマンドプロンプトごと終了させました。

当然chkdskによってG:ドライブはアンマウントされているので再マウントしようとしましたがうまくいきません。焦っていると「すわ、壊したか!」と慌てるところですが、ここは、理屈ではここは単純にリブートで行けるはずと踏んでリブートするとG:ドライブが復活しました。

そこで改めてG:ドライブのファイルを閲覧したりすると、やっぱり奇妙に重い。今のところ何の解決にもなっていないことは明らかですので、SMART値を精査することにしました。

すると、「UltraDMA CRC エラー数」が膨大な値になっていることが分かりました。

これらをWindowsのイベントログを見ると
ソース:disk
イベントID: 153
「ディスク 1 (PDO 名: \Device\00000031) の論理ブロック アドレス 0x600870 で IO 操作が再試行されました。」
※論理ブロックアドレスは一定ではありません

というログが記録されています。

以下のようなログもありました
「トランザクション ログへのデータのフラッシュに失敗しました。VolumeId: G:、DeviceName: \Device\HarddiskVolume7 で破損が発生している可能性があります。」
以下HDD型式などの情報

ともあれ、SMART値が示すところでは、HDDとの通信がうまくいかないでエラーが起きてることを示しているので、最悪の場合はマザーボードの故障ですが、まずはSATAケーブルの交換を試してみます。

...正常に稼働するようになりました。

地味だけど重要な仕事をしてくれている伝送路を担うケーブルさんに感謝するためここに記録する次第です。

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

S.M.A.R.T.値などで異常を示したST3000DM008で遊んでみよう

新規購入した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.out Checking blocks 0 to 732566271 100.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       -       6 183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0 184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0 187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       262 188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0 189 High_Fly_Writes         0x003a   099   099   000    Old_age   Always       -       1 190 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       -       0 192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       4 193 Load_Cycle_Count        0x0032   073   073   000    Old_age   Always       -       55928 194 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       -       1112 198 Offline_Uncorrectable   0x0010   094   094   000    Old_age   Offline      -       1112 199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0 240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       32556h+15m+05.395s 241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       25786278431 242 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/sdd1 debugfs 1.42.9 (28-Dec-2013) Block   Inode number 524726232       117966080

ばっちり使われています。

使われていない場合は次のような表示になります。

1 2 3 4

# debugfs -R "icheck 620236906" /dev/sdd1 debugfs 1.42.9 (28-Dec-2013) Block Inode number 620236906 <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=524726232 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.00141101 秒、 2.9 MB/秒 # sync # smartctl -a /dev/sdd1 ID# 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       -       1104 198 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       -       8 197 Current_Pending_Sector  0x0012   100   094   000    Old_age   Always       -       0 198 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/sdd1 e2fsck 1.42.9 (28-Dec-2013) /dev/sdd1: Updating bad block inode. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #18928 (23698, counted=23699). Fix<y>? yes Free blocks count wrong for group #19312 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #20416 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #22000 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #22032 (24542, counted=24544). Fix<y>? yes Free 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コマンドで総なめしてみて、何か面白いことが起きるかどうかですかねえ。

まずは今回はこんなところでしょうか。

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