smartmontools でエラーが出た HDD の扱い
smartmontools とは
- ストレージデバイスから S.M.A.R.T. 情報を集めるツール
S.M.A.R.T. について
出典: フリー百科事典『ウィキペディア(Wikipedia)』
Self-Monitoring, Analysis and Reporting Technology (セルフモニタリング・アナリシス・アンド・リポーティング・テクノロジー、略称: S.M.A.R.T.; スマート) は、ハードディスクドライブと、ソリッドステートドライブの障害の早期発見・故障の予測を目的としてディスクドライブに搭載されている機能である。この機能は、各種の検査項目をリアルタイムに自己診断し、その状態を数値化する。ユーザーはその数値を各種のツール(後述)を用いることで知ることが出来る。
smartmontools の使用
- 以前使った時、対象はIDE-HDD(SATA)だけかと思ったら、SCSIにも対応していて、Versionが進むにつれて SAS/SSD からも情報が出る。
- smartd を常駐させて監視させることもできる。
- NVMe にも対応しているが FreeBSD では、 /dev配下にある nvme[0-9*] が S.M.A.R.T.に応答する。FreeBSDの場合は、"nda" デバイスは
NVMe Direct Access device driver
で、デバイスアクセスのみ対応するものとして分離されており、状態管理は core ドライバの nvme[?] などからアクセスできる。
本題: READエラーが出てOSで扱えなくなった HDDを取り敢えず使えるようにしてしまう方法・・・
-
信頼性の面から '' オススメ'' 出来ないことだが、テスト目的:インストールテストをするデバイス、取り敢えずデータをぶん投げる「テスト」だけに使うデバイスで保管を目的にしない ストレージってのは、そこそこ需要がある。
-
ゴミ箱HDD扱いで、OSで「こいつぁもう壊れてんぞ」扱いするのは、S.M.A.R.T.だけでなく、zfs では pool の管理記録に記録されてしまって扱えなくなってしまう。 まあ、zpoolを作り直すのもあるのだが、それでも「このセクタは読めません」的な情報がきちんとハード的に処理されてないと、しばらくすると当該セクタに書き込んだものを読もうとして失敗し、自動で切り離されてしまう。
-
smartctl で テストを掛けて「どこのセクタが壊れたのか」をチェックすることはできる。
# 1 Extended offline Completed: read failure 90% 13775 1763221420
# 2 Extended offline Completed: read failure 90% 13775 1763221416
# 3 Extended offline Completed: read failure 90% 10112 1763221420
# 4 Extended offline Completed: read failure 90% 6729 1763221416
# 5 Extended offline Completed: read failure 90% 6112 32
# 6 Extended offline Completed: read failure 90% 6112 32
# 7 Extended offline Completed: read failure 90% 6062 32
- チェック残り 90% もある中でエラーが出てしまうと、ほとんど使えないと認識されている。
取り敢えず更地にしてしまう
そこで、dd コマンドで こんな困った HDD を 一旦 更地にしてしまう。
-
もし読み出せるファイルシステムが残っているなら、データを保存しておく。
-
読めなくなっていたら、 testdisk/photorec で救出を試みること。
→ https://github.com/cgsecurity/testdisk リカバリのことについてはそのうち書こうと思う。 -
dd コマンドの例:
# dd if=/dev/zero of=/dev/da1 bs=4096 status=progress
-
FreeBSD などでは、 dd コマンドが拒否されることもある。 そんなときはこれを読む。https://forums.freebsd.org/threads/dd-operation-not-permitted-error.85787/
sysctl kern.geom.debugflags=0x10
-
dd で 更地にすると まず「書き込める」デバイスであるということがはっきりする。つまりヘッダであるとかモータの回転がおかしいとか、致命的な故障はないこと。たまたま読み出せなくなったところがある=磁化作用が働かない場所が出来たということ。
-
HDDがもつ全セクタへのdd は「論理的に整列されたセクタにシーケンシャルに書いていく」という建前があるが、現実はセクタスキューがあって飛び飛びではある。とはいえ触っていないトラックは一つもなく、全トラックの上にヘッダが存在していたことが保証される。これはいわゆる論理フォーマットでは出来ない「検証作業」とも言える。
-
かつてRAIDが可能なHBAでは、ファームウエアがこの作業を時間専有して行ったりする。ただ、これはユーザにとっては苦痛でしかない。 なんでHBAファームウエアみたいな貧弱なUIで何時間も下手すれば数日機材に通電しているのか!?となってしまう。 その点 dd であれば、少なくとも健全な他の資源を使いながらできる。かつての鉄板 Adaptec/HBAあたりだとこの辺はやや改善もあったのだが 大抵の miror/RAID HBAというのは高度な処理もクソもなく「ゴミ」にも等しいただのコピーをしていてあの価格で品質であって、性能がほとんど期待できないという酷いモノが多かった。騙されたのは私だけではなかろう。
-
健全な HDD であれば、 dd で書き込みをしているときに、S.M.A.R.T.情報提供するHDDユニットで「セクタ代替処理」が働いてくれると期待する。
-
smartctl でチェックするだけでは この「代替処理」大昔の IDE/ST-506 では手作業だった「デフェクトリスト更新」をしない。おそらく「書き込み処理」が成功したかで代替セクタ処理が働くのだと思われる。 OSやファイルシステム-サブシステム側でこの処理を対応した後に「エラー警告」だすのもありなのだが、ここでユーザを甘やかすと結果的にユーザを地獄に落とすことになるので敢えて「使えません」としてしまうのは正しい。
-
本稿でテストしているユニットは、消費電力を削るために スピンドルモータの回転 ON/OFFを自動でするもので、なにやら OSが対応していないとロードサイクルカウントをバク上げして自壊するという 悪名高い WD-Greenの第一世代 1TBである。
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 - 252
3 Spin_Up_Time 0x0027 142 133 021 Pre-fail Always - 3883
4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6913
5 Reallocated_Sector_Ct 0x0033 198 198 140 Pre-fail Always - 112
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 082 082 000 Old_age Always - 13802
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1784
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 82
193 Load_Cycle_Count 0x0032 103 103 000 Old_age Always - 293296
194 Temperature_Celsius 0x0022 108 105 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 097 097 000 Old_age Always - 103
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 120
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 197 000 Old_age Offline - 120
* dd で full-sector '0' 埋め する前に
197 Current_Pending_Sector
の数値が 100 近くあった。 今は 0 なので
5 Reallocated_Sector_Ct 0x0033 198 198 140 Pre-fail Always - 112
112 セクタ が リアロケされたということである。
- smartctl で self-test(long) をかける。コレが結構時間を要する。
data collection: (14100) seconds.
3時間から4時間か。 リアロケーションされてエラーが出ないかどうかを検証する。
- OKなら zpool なり拵えてストレステストしてみる。
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 13803 -
# 2 Extended offline Completed: read failure 90% 13775 1763221420
# 3 Extended offline Completed: read failure 90% 13775 1763221416
# 4 Extended offline Completed: read failure 90% 10112 1763221420
# 5 Extended offline Completed: read failure 90% 6729 1763221416
# 6 Extended offline Completed: read failure 90% 6112 32
# 7 Extended offline Completed: read failure 90% 6112 32
# 8 Extended offline Completed: read failure 90% 6062 32
error は消えたようだ。
zpool テスト
- dd で何かを書ける環境を作る。
# gpart show da1
=> 40 1953525088 da1 GPT (932G)
40 1953525088 - free - (932G)
root@server:~ # gpart add -t freebsd-zfs da1
da1p1 added
root@sv20240314:~ # gpart show da1
=> 40 1953525088 da1 GPT (932G)
40 1953525088 1 freebsd-zfs (932G)
root@server:~ # zpool create ztank da1p1
root@server:~ # zpool status ztank
pool: ztank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
ztank ONLINE 0 0 0
da1p1 ONLINE 0 0 0
errors: No known data errors
root@server:~ # cd /ztank
root@server:/ztank # dd if=/dev/random of=testdata.bin bs=4096 status=progress
-
931.5GB を 100 〜 150M/s くらいで埋めていく。多く見積もって7000秒、2時間近い。100GB書いたところで700秒である。
-
最初は150MB/sで書き込み処理が追いつかなくなって速度が落ちた。 zfs の基本書き込みレコードサイズは 128kbytes だが、最近の HDDは 4Kセクタであるから、4k単位を dd に指示した。無論、キャッシュで読み書きが完結するなら bs=128k が最速になるはずだが 物理媒体が 4k単位なんだからそれより大きくしても変わるまい。
-
dd 処理は core 1 個で WCPU=92% 少し使っている。作業しているサーバのチップセットは wellsburg-C610で、富士通さんの調べによれば 1.7Gb/sくらいが限界だと書いている. https://sp.ts.fujitsu.com/dmsp/Publications/public/wp-raid-controller-performance-2016-ww-ja.pdf
-
↑ PRAID CM400i は持っているけど どうやら MS-WindowsやRHELの SASで使うものだと思う。 near-line SATA のユニット でドライバがしっかりと対応してない FreeBSD で使うと涙が出るほどまぢ死ぬほど *** 遅い *** 。 取っ払って Sunrize Point/C256 のAHCIの接続に替える まではサーバが落ちたかと思うほど反応が遅くなっていた。
-
テスト中、swap out に異常が生じるなど、サーバに対する負荷が異常に高くなったので中断した。
-
この手の実験は手元でやるべし。
オワコンのHDDに対する考察
- 1ユニットで20TBくらいの容量になってくると、容量に対するコストでまだまだオワコンとは言い切れない。 NVMe で 4TBを超えてくると 安くても 100,000JPY に届いてしまう
- 2010年代以後のエンプラ向け大容量 HDDは壊れにくい。ホビーユースのHDDでも2000年代の比ではなく、きちんと温湿度管理されて電源の変動がないなら 10年経ってもなかなか壊れてくれない(無論壊れろといわない)
- HDD保存の問題は、長期間放置しておくとモーターが劣化したり、プラッタが劣化して読めなくなること。
- 磁気記録の劣化問題対策全般で、保管データを相当長期運用するのであれば、全てデータを別の媒体に移して「バルクフォーマット」的な作業をしたほうが良いと考えられる。太古の6250テープなどは再書き込みをするよりは媒体ベースのアセテート樹脂の崩壊やら磁性体のバインダーが劣化して剥がれたりするから単にコピーするだけ。
- ローテーションが大事: HDDバックアップで、世代ローテーションを組んでフルダンプ+差分を、異なるメディアに行っているが、いつでも読み書きできるデバイスとして認識可能となっていることも保証できる。
- 大昔のVAXのディスクは「ホールのケーキ」を運ぶようなデシケータ上のケースに収まっていて、これを取り替えていた。
- LTOデバイスと比較すると、バイト単価は全然勝てるはずがない。LTOはドライブが結構するのと後述の利点がないので、真正性を保証しろとフルダンプでしか動作保証しないシステムでシステムが壊れたら大惨事でその後片付けに使う程度のもの。掛け捨て保険。
- 基本的にテープに比べランダムアクセスに優れるので、個別の消去ファイルに対応するとかちょっと探しものがしたいというユースケースに対応して、ファイルシステムそのままバックアップするのが普通。テープデバイスを模してTARballして保管する先ではない。
Discussion