ふるた技工所(てっこうしょ)

キーワードサーチ

▼キーワード検索

プロフィール

Aちゃん22

フリーページ

2019.10.21

データドライブが壊れた (2) - クローニングが上手くいかない

カテゴリ：ソフト開発日誌

データドライブが壊れた (1)

sg3_utils の sg_dd を修正したものを使う。sg_dd は SCSI command で直接ドライブをアクセスする dd コマンドだ。dd コマンドを使わない理由は、リトライを頻発させて、DID_BAD_TARGET, DID_NO_CONNECT, あるいは "rejecting I/O to offline device" になってしまう可能性を下げるためだ。

次のコマンドでコピーを開始する。/dev/sdd は障害があるドライブ、/dev/sde はクローン先のドライブ、abortrep, abortnum は拡張したパラメータだ。素の sg_dd には存在しない。いずれもっと使いやすいコマンドに仕立て直したい。

sg_dd if=/dev/sdd of=/dev/sde bpt=16 bs=512 iflag=coe,sgio abortrep=0 abortnum=10240 coe=1 time=1 skip=0 seek=0

初め bpt=512 としていた。1 回の SCSI command 当たり 512 block を転送する指定だ。bpt=512 は良くないことが分かった。512 block のうち複数箇所に障害があると、ドライブ内部のエラー回復リトライが増えて、timeout 至り、デバイスドライバがドライブを切断 (offline) してしまう機会が増えてしまった。クローニング作業が中断してしまう。

認識すらできない可能性があるドライブだ。作業をやり直す機会は僅かしかない。bpt が小さい値だと、転送効率が下がりクローニング時間は延びる。クローニング出来ない致命的な事態は第一優先で避ける。bpt=16 とした。これでも失敗するなら bpt=8 (AFT block size の 4Kibyte) なのかな...

これでメイン PC のドライブはクローニングができた。sg_dd の出力から、688.5Kibyte 分の不良ブロックがある。

約 67 万個あるファイルのうちどれが壊れたのだ？

作業過程で知り得たことを正確に書くと、クローニングが終わった時点でドライブに格納されたファイル数は把握できていなかった。「全部で 1.5T byte になるファイルのうちいくつかが壊れた。」というぼんやりとした認識だ。

クローニングをしたドライブを Linux マシンから windows マシンに付け替えて chkdsk /f を掛ける。エラー出力、修復動作は行われなかった。ファイル管理構造は壊れていない。全てのファイルは中身は壊れたかもしれないけれど、存在はしている。

クローンとなったドライブを (2) のコピー先とファイル単位で照合することにした。

照合していると、サーバー上にファイルが無いエラーが発生し、以降継続的にエラーが発生する。最初から試しても、ほぼ同じようなファイルを照合する辺りでエラーが継続してしまう。

サーバーのログを見てみる。Synchronize Cache(10)、場合によっては Read(16) を含めて、bus reset を繰り返している最中に、"rejecting I/O to offline device" になり、バックアップ先のドライブを見失っている。

[ 6927.678052] sd 6:0:0:0: [sdg] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[ 6927.678063] sd 6:0:0:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 01 bc 2c 8f 80 00 00 02 00 00 00
[ 6957.749432] sd 6:0:0:0: [sdg] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
[ 6957.749443] sd 6:0:0:0: [sdg] tag#1 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[ 6957.749452] scsi host6: uas_eh_bus_reset_handler start
[ 6957.821569] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd
[ 6957.840875] scsi host6: uas_eh_bus_reset_handler success
[ 6988.668563] sd 6:0:0:0: [sdg] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[ 6988.668575] sd 6:0:0:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 01 bc 2c 8f 80 00 00 02 00 00 00
[ 7018.676035] sd 6:0:0:0: [sdg] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
[ 7018.676046] sd 6:0:0:0: [sdg] tag#1 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[ 7018.676055] scsi host6: uas_eh_bus_reset_handler start
[ 7018.752588] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd
[ 7018.772325] scsi host6: uas_eh_bus_reset_handler success
[ 7018.772680] sd 6:0:0:0: [sdg] tag#1 Medium access timeout failure. Offlining disk!
[ 7018.772688] sd 6:0:0:0: Device offlined - not ready after error recovery
[ 7018.772703] sd 6:0:0:0: [sdg] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[ 7018.772709] sd 6:0:0:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 01 bc 2c 8f 80 00 00 02 00 00 00
[ 7018.772713] blk_update_request: I/O error, dev sdg, sector 7452004224
[ 7018.772764] sd 6:0:0:0: rejecting I/O to offline device
[ 7018.772789] sd 6:0:0:0: rejecting I/O to offline device
[ 7018.772794] sd 6:0:0:0: [sdg] killing request
[ 7018.772817] sd 6:0:0:0: [sdg] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 7018.772823] sd 6:0:0:0: [sdg] CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[ 7018.772828] blk_update_request: I/O error, dev sdg, sector 3917744192
[ 7018.772852] Aborting journal on device sdg3-8.
[ 7018.772887] sd 6:0:0:0: rejecting I/O to offline device
[ 7018.772904] JBD2: Error -5 detected when updating journal superblock for sdg3-8.
[ 7019.777687] sd 6:0:0:0: rejecting I/O to offline device
[ 7019.777742] sd 6:0:0:0: rejecting I/O to offline device

バックアップ先にも障害がある。何が原因だろうか？

ディスクドライブに障害がある
→ 障害があってもハングしないハードディスクケースに変える。または、ドライブをクローニングする
USB/SATA ブリッジチップ ASM1053 またはファームウエアにバグがあり、状況により UASP 処理がおかしくなる
→ ハードディスクケースを変える。または、 Linux の UAS ドライバを使わないようにする。
Linux の UAS ドライバが未熟(stack dump とか見るしなぁ)
→ ハードディスクケースを変える。または、 Linux の UAS ドライバを使わないようにする。

考えられる原因に対する対応方法からすると、ハードディスクケースを外して開ける必要がある。ケースは玄人志向 GW3.5TV-SU3/SV だ。

ブリッジチップは Asmedia ASM1053 を使用している。

ハードディスクケースの動作状況を見ているとアクセスランプが全く点かない。リブート時、"offline device" になる前の正常アクセスできる状態でもランプが点かない。

気づいたときには複数の障害が溜まっている典型的な状態になっていた。バックアップ先に使っているハードディスクは一度不良ブロックを出したものだったのも致命的な運用だった。パーティションを切り直して避ければ良いと考えていた(経験的に避けても不良ブロックは広がりやすい)。

この時点で当初の見込みと比べ作業量は 2 ～ 3 倍になる。続くなぁ...

2019.10.25 追記
データドライブが壊れた (1) - バックアップドライブも壊れていた
データドライブが壊れた (3) - 壊れたファイルはダウンロード、コピー元が存在すると判明

お気に入りの記事を「いいね！」で応援しよう