2019.05.13
カテゴリ： ソフト開発日誌
Windows 10 システムイメージを格納している WDC WD10J31X SSHD が壊れてしまった。奇妙な壊れ方だ。全 block 読み出しできる。書き込みができない。
壊れた WD10J31X から状況を採取する。 smartctl -a , smartctl -x , hdparm -I それぞれのリンク先はテキストファイルだ。SMART 情報を読んだ限りは、14065 時間使われ、それなりに使用感はある。約 1.6 年で十分に現役だろう。エラーは皆無、元々ログ機構が無いのか、何が起きたのかは読み取れない。まるで正常なのだ。
格納されたデータを壊さないように partition として使われていない領域を read, write してみる。Last LBA 付近は使われていない。size は AFT サイズ 4KiByte とした。/dev/sdb は WD10J31X の block device node だ。
[読み出し]
[書き込み]
書き込みの手応えが何かおかしい。dd の出力からも分かるように転送に時間が掛かりすぎる。何回か試しても数 kB/s から 10 数 kB/s 台だ。dmesg で kernel log を見てみることにした。 起動直後からの kernel log kernel log から WD10J31X 書き込みエラー部分を抜粋
dd command がエラー終了とならずに kernel log にエラーが残ることがあるのか。気をつけないと。
何かのページで SSHD は Flash Memory が損耗限界に達したら、ただの HDD になるだけだと読んだことがある。違うようだ。読み出せるのに書き込めない原因として最もらしいのは、Flash Memory が損耗してしまい、Flash Memory 書き込みエラーが Write Command を error にしているという状況だ。
別の状況も考えられる。Flash Memory を代替領域として使っているとする。Flash Memory が損耗限界に達したか代替数の上限に達したところで、代替不能になり書き込みを受け付けなくなっている。考えにくい。従来通り、プラッタの一部を代替領域にするのが妥当な実装だと思う。
SSHD を作るときにライフサイクル全体を通してどんな挙動をするべきなのか？ 仕様検討が不十分なのか、実装、テストが不十分なのか、未成熟のまま市場に出したような...
ここで区切って、ことの始まりから書く。
メインで使ってる PC がフリーズしだす、ネットの動画を見ていたら止まった。どの window も閉じることができず、task manager を使った終了もできなくなった。シャットダウンも止まる。リセット・電源 off/on を何回かしても、起動途中で HDD アクセスランプが点きっぱなしで停止、10 分ほど待つと Blue screen "0x000000ED UNMOUNTABLE_BOOT_VOLUME" が出て再起動する。
この時点で起動ドライブ WD10J31X か swap file を格納している SSD のどちらかが故障していると考えていた。"UNMOUNTABLE_BOOT_VOLUME" なので起動ドライブが故障していると考えるのが一番妥当だろう。
セーフモード起動はできず。 Windows 10 のインストールメディアを作成 し、修復セットアップを試みる。mediacreationtool1809.exe は半日くらい経つと、失効するのだろうか？時間が経つとメディア作成に失敗する。
この状況は良くない。read できない block が多数発生し、致命傷に至る前に手を打つべきだ。クローン作成とクローンを使った修復作業をする方針に切り替える。
clonezilla で全バックアップ、エラー無しで終了する。リストア作業に失敗する。clonezilla による作業は断念した。信頼できないツールを非常事態に使うのは危険だ。
保守用に買っておいた TOSHIBA MQ02ABD100H に dd で全コピーすることにした。こちらも 1Tbyte で同一容量だ。512byte LBA 数も 1953525168 で完全に一致する。コマンドラインの斜字体部分は該当するドライブに割り当てた [a-z] の文字になる。
# dd if=/dev/sd WD10J31X_block_device of=/dev/sd MQ02ABD100H_block_device bs=8192
bs を 8KiByte にしたのは、(1953525168 * 512) のもっとも大きな 2^n を満たす約数だからだ。小さい値だ。確実に余りなくコピーできるのだから、時間は犠牲にしよう。
次にディスクイメージを VirtualBox Disk Image file (VDI) ファイルとして保存する。qemu-img コマンドを使用して次の様に作成した。これで何度でも色々な方法で修復作業を試せるようになる。
# qemu-img convert -O vdi /dev/sd WD10J31X_block_device backup-image-file .vdi
平行して、別の Windows 10 PC を久しぶりに電源を入れて、最新の更新状態にする。chkdsk /f 中にリブートするのは悲劇だからだ。
別の Windows 10 PC に全コピーでクローンになった MQ02ABD100H を接続する。chkdsk /f を実行する(と言うより Windows 起動中に自動的に修復が始まった)。1 時間ほど掛かっただろうか？起動終了後にディレクトリ、ファイルの存在を確認してみる。普通にエクスプローラで見ることができ、2, 3 分で見られる範囲で欠損は見当たらなかった。
MQ02ABD100H を メインで使ってる PC へ接続する。起動を試みる。プロダクトキー認証で何かいわれたら、「ハードディスク故障です」で交渉するつもりだった。再認証などは特に行われず、起動した。
時刻がなぜか故障で動かなくなった時刻の 4, 5 時間前になっていた。4, 5 時間前に故障事象が発生していたのだろうか？イベントログが更新されなくなったのも、時計が止まった時刻近辺だ。ネットワーク時刻に同期して時刻を修正する。
暫く使う、問題は起きず。溜まっていたメールも読め、サーバーに保留していたメールも受信し読める。ネット接続に大きな問題はなし。
MQ02ABD100H も SSHD なんだよなぁ... 検索してみると アマゾンのレビューが見つかる 直ぐに壊れるとな...
壊れた WD10J31X から状況を採取する。 smartctl -a , smartctl -x , hdparm -I それぞれのリンク先はテキストファイルだ。SMART 情報を読んだ限りは、14065 時間使われ、それなりに使用感はある。約 1.6 年で十分に現役だろう。エラーは皆無、元々ログ機構が無いのか、何が起きたのかは読み取れない。まるで正常なのだ。
格納されたデータを壊さないように partition として使われていない領域を read, write してみる。Last LBA 付近は使われていない。size は AFT サイズ 4KiByte とした。/dev/sdb は WD10J31X の block device node だ。
[読み出し]
# dd if=/dev/sdb skip=1953525160 count=8 | od -A x -t x1
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8+0 records in
8+0 records out
*
001000
4096 bytes (4.1 kB) copied, 0.000371121 s, 11.0 MB/s
→ エラー発生せず。000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8+0 records in
8+0 records out
*
001000
4096 bytes (4.1 kB) copied, 0.000371121 s, 11.0 MB/s
[書き込み]
# dd if=/dev/zero of=/dev/sdb seek=1953525160 count=8
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 2.58513 s, 1.6 kB/s
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 2.58513 s, 1.6 kB/s
書き込みの手応えが何かおかしい。dd の出力からも分かるように転送に時間が掛かりすぎる。何回か試しても数 kB/s から 10 数 kB/s 台だ。dmesg で kernel log を見てみることにした。 起動直後からの kernel log kernel log から WD10J31X 書き込みエラー部分を抜粋
[ 3662.119993] ata4.00: limiting speed to UDMA/33:PIO4
[ 3662.120001] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
[ 3662.126450] ata4.00: irq_stat 0x00060002, device error via D2H FIS
[ 3662.132622] ata4.00: failed command: WRITE DMA EXT
[ 3662.137412] ata4.00: cmd 35/00:08:a8:6d:70/00:00:74:00:00/e0 tag 22 dma 4096 out
[ 3662.137412] res 61/04:08:a8:6d:70/00:00:74:00:00/e0 Emask 0x1 (device error)
[ 3662.152601] ata4.00: status: { DRDY DF ERR }
[ 3662.156863] ata4.00: error: { ABRT }
[ 3662.160432] ata4: hard resetting link
-- snip --
[ 3664.792020] sd 3:0:0:0: [sdb]
[ 3664.792023] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 3664.792026] sd 3:0:0:0: [sdb]
[ 3664.792028] Sense Key : Hardware Error [current] [descriptor]
[ 3664.792032] Descriptor sense data with sense descriptors (in hex):
[ 3664.792033] 72 04 44 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 3664.792044] 74 70 6d a8
[ 3664.792049] sd 3:0:0:0: [sdb]
[ 3664.792052] Add. Sense: Internal target failure
[ 3664.792055] sd 3:0:0:0: [sdb] CDB:
[ 3664.792057] Write(10): 2a 00 74 70 6d a8 00 00 08 00
[ 3664.792073] end_request: I/O error, dev sdb, sector 1953525160
[ 3664.797902] Buffer I/O error on device sdb, logical block 244190645
[ 3664.804168] lost page write due to I/O error on sdb
[ 3664.804175] ata4: EH complete
エラーが発生していた。書き込めない。[ 3662.120001] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
[ 3662.126450] ata4.00: irq_stat 0x00060002, device error via D2H FIS
[ 3662.132622] ata4.00: failed command: WRITE DMA EXT
[ 3662.137412] ata4.00: cmd 35/00:08:a8:6d:70/00:00:74:00:00/e0 tag 22 dma 4096 out
[ 3662.137412] res 61/04:08:a8:6d:70/00:00:74:00:00/e0 Emask 0x1 (device error)
[ 3662.152601] ata4.00: status: { DRDY DF ERR }
[ 3662.156863] ata4.00: error: { ABRT }
[ 3662.160432] ata4: hard resetting link
-- snip --
[ 3664.792020] sd 3:0:0:0: [sdb]
[ 3664.792023] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 3664.792026] sd 3:0:0:0: [sdb]
[ 3664.792028] Sense Key : Hardware Error [current] [descriptor]
[ 3664.792032] Descriptor sense data with sense descriptors (in hex):
[ 3664.792033] 72 04 44 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 3664.792044] 74 70 6d a8
[ 3664.792049] sd 3:0:0:0: [sdb]
[ 3664.792052] Add. Sense: Internal target failure
[ 3664.792055] sd 3:0:0:0: [sdb] CDB:
[ 3664.792057] Write(10): 2a 00 74 70 6d a8 00 00 08 00
[ 3664.792073] end_request: I/O error, dev sdb, sector 1953525160
[ 3664.797902] Buffer I/O error on device sdb, logical block 244190645
[ 3664.804168] lost page write due to I/O error on sdb
[ 3664.804175] ata4: EH complete
dd command がエラー終了とならずに kernel log にエラーが残ることがあるのか。気をつけないと。
何かのページで SSHD は Flash Memory が損耗限界に達したら、ただの HDD になるだけだと読んだことがある。違うようだ。読み出せるのに書き込めない原因として最もらしいのは、Flash Memory が損耗してしまい、Flash Memory 書き込みエラーが Write Command を error にしているという状況だ。
別の状況も考えられる。Flash Memory を代替領域として使っているとする。Flash Memory が損耗限界に達したか代替数の上限に達したところで、代替不能になり書き込みを受け付けなくなっている。考えにくい。従来通り、プラッタの一部を代替領域にするのが妥当な実装だと思う。
SSHD を作るときにライフサイクル全体を通してどんな挙動をするべきなのか？ 仕様検討が不十分なのか、実装、テストが不十分なのか、未成熟のまま市場に出したような...
ここで区切って、ことの始まりから書く。
メインで使ってる PC がフリーズしだす、ネットの動画を見ていたら止まった。どの window も閉じることができず、task manager を使った終了もできなくなった。シャットダウンも止まる。リセット・電源 off/on を何回かしても、起動途中で HDD アクセスランプが点きっぱなしで停止、10 分ほど待つと Blue screen "0x000000ED UNMOUNTABLE_BOOT_VOLUME" が出て再起動する。
この時点で起動ドライブ WD10J31X か swap file を格納している SSD のどちらかが故障していると考えていた。"UNMOUNTABLE_BOOT_VOLUME" なので起動ドライブが故障していると考えるのが一番妥当だろう。
セーフモード起動はできず。 Windows 10 のインストールメディアを作成 し、修復セットアップを試みる。mediacreationtool1809.exe は半日くらい経つと、失効するのだろうか？時間が経つとメディア作成に失敗する。
この状況は良くない。read できない block が多数発生し、致命傷に至る前に手を打つべきだ。クローン作成とクローンを使った修復作業をする方針に切り替える。
clonezilla で全バックアップ、エラー無しで終了する。リストア作業に失敗する。clonezilla による作業は断念した。信頼できないツールを非常事態に使うのは危険だ。
保守用に買っておいた TOSHIBA MQ02ABD100H に dd で全コピーすることにした。こちらも 1Tbyte で同一容量だ。512byte LBA 数も 1953525168 で完全に一致する。コマンドラインの斜字体部分は該当するドライブに割り当てた [a-z] の文字になる。
# dd if=/dev/sd WD10J31X_block_device of=/dev/sd MQ02ABD100H_block_device bs=8192
bs を 8KiByte にしたのは、(1953525168 * 512) のもっとも大きな 2^n を満たす約数だからだ。小さい値だ。確実に余りなくコピーできるのだから、時間は犠牲にしよう。
次にディスクイメージを VirtualBox Disk Image file (VDI) ファイルとして保存する。qemu-img コマンドを使用して次の様に作成した。これで何度でも色々な方法で修復作業を試せるようになる。
# qemu-img convert -O vdi /dev/sd WD10J31X_block_device backup-image-file .vdi
平行して、別の Windows 10 PC を久しぶりに電源を入れて、最新の更新状態にする。chkdsk /f 中にリブートするのは悲劇だからだ。
別の Windows 10 PC に全コピーでクローンになった MQ02ABD100H を接続する。chkdsk /f を実行する(と言うより Windows 起動中に自動的に修復が始まった)。1 時間ほど掛かっただろうか？起動終了後にディレクトリ、ファイルの存在を確認してみる。普通にエクスプローラで見ることができ、2, 3 分で見られる範囲で欠損は見当たらなかった。
MQ02ABD100H を メインで使ってる PC へ接続する。起動を試みる。プロダクトキー認証で何かいわれたら、「ハードディスク故障です」で交渉するつもりだった。再認証などは特に行われず、起動した。
時刻がなぜか故障で動かなくなった時刻の 4, 5 時間前になっていた。4, 5 時間前に故障事象が発生していたのだろうか？イベントログが更新されなくなったのも、時計が止まった時刻近辺だ。ネットワーク時刻に同期して時刻を修正する。
暫く使う、問題は起きず。溜まっていたメールも読め、サーバーに保留していたメールも受信し読める。ネット接続に大きな問題はなし。
MQ02ABD100H も SSHD なんだよなぁ... 検索してみると アマゾンのレビューが見つかる 直ぐに壊れるとな...
お気に入りの記事を「いいね！」で応援しよう
[ソフト開発日誌] カテゴリの最新記事
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
-
Intel Core i5-10600K 偽物説 - 近所の HA… 2023.09.04
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
© Rakuten Group, Inc.
