🥶

smartmontools でエラーが出た HDD の扱い

2025/01/29に公開

smartmontools とは

https://www.smartmontools.org/

  • ストレージデバイスから 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