2019.10.24
カテゴリ： ソフト開発日誌
バックアップ先のハードディスクを別のケースに入れることにした。予備で買っておいた UNITCOM の UNI-HAL35 を化粧箱から出す。買ったときにブリッジチップを確かめていれば、USB 接続は早々にあきらめて、SATA 接続でクローニングを始めていたと思う。
基板を確かめてみる。12V から 5V に降圧するスイッチングレギュレーターの IN, OUT 両方のコンデンサが高リプルに耐えられるかどうか怪しい。105 ℃規格品なのは確かだ。インダクタも開磁路型なのでノイズ放射が大きい。
ブリッジチップの刻印を読む、JMS567 だ。ファームは何だろうか？使ってみたところ、ランプの点き方は Version 138.01.00.01
かその派生の様に見える。
コンデンサとインダクタを交換する。場合によっては長く使うかもしれない。コンデンサは東信 UTWRZ 25V 220uF に交換、並列に MLCC 25V 10uF Z class、インダクタは準閉磁路型(狭いギャップがある)で同一定数 33uH に交換する。ブリッジ線を入れたのは、部品を外す時にパターンを痛めたので補強した。半田ごてを二刀流で使えばよかったかも。
導通・非導通チェック、基板単体動作で電圧チェックをする。主要な電源ライン 12V, 5V, 3.3V を確認できた。問題なし。
ここまで手を入れた UNI-HAL35 は結局使わないことにした。先の Asmedia ASM1053 を使った 玄人志向 GW3.5TV-SU3/SV と同じ挙動になる。同じようなファイルを読みだしたところで、USB 接続が切れてしまう。ハードディスクに問題が有ると考えた。
先にバックアップ先のハードディスクの不良ブロックマップを出す。これも、実際の作業流れではクローニング完了後に分かる情報だ。
画像をクリックすると PDF を開きます。
先に言及した通り、このドライブは 2016/10 に不良ブロックが発生している。次が 2016/10 時点の不良ブロックマップだ。Zero Fill をして不良ブロックを代替して使い始める(代替すると不良ブロックが消えたように見える)。
画像をクリックすると PDF を開きます。
不良ブロックは近隣にじわじわと広がらず、飛び火する様に広がっていた。この壊れ方ではパーティションを切って使わないようにしたり、fsck.ext4 の -l または -L オプションで拡大的な不良ブロックリストを指定して避けても、効果はない。
USB 接続では安定したクローニングができない。SATA 接続にして、クローニングを行う。データドライブと同様に sg_dd を使用してクローニングをした。不良ブロックの近辺でいわゆる「低速病」になった。16block を読み出すのに 1 ～ 2 秒ほど掛かる状態が 1 日程度続く。途方もなく長い作業を覚悟した。終わってみれば全ブロックをコピーする速度は 23.09 Mbyte/sec だった。
「低速病」の原因の一つは、不良になりかかったブロックのエラー訂正、あるいは何かの条件を変更した読み出しを行ってデータ修復を行う動作なのか。
遅いクローニングに並行して照合作業を迅速に行う方法を調査・検討していた。cmp コマンドで双方のファイルを一つ一つ読み出し byte to byte で比較すると数日では終わらないことが分かってきた。
多少冗長なスクリプト(リンク先はスクリプトのソース) で、一つ一つの md5sum を計算し、パス名を正規化(パスからマウントポイントを削除する), sort, diff を行い差分から、破損、喪失(ないはず) ファイルを見つけることにした。
CDir1=/mnt/sdd3/furuta/backup2nd/whitenine-2nd # path to mount backup root
if [ -n "$1" ]
then
CDir1="$1"
fi
CDir1T="${CDir1}"
if ( ! echo "${CDir1}" | grep -q '/$' )
then
CDir1T="${CDir1}/"
fi
(cd "$CDir1"; find . -name '*') |
while read
do
File1="${CDir1T}${REPLY}"
if [ -d "${File1}" ]
then
continue
fi
sum=`md5sum "${File1}" | cut -f 1 -d ' '`
echo "\"${File1}\" ${sum}"
done
厳密にいえば md5sum は全く別のバイナリ列が同一値を示す場合もある。ファイルにブロック単位で 0x00 の穴を空けて、偶然に md5sum が一致することはほぼ無いと考えている。もし、一致することが有るならば md5sum に対してハッシュ衝突をするバイナリ列の生成方法に多くの手法が考案され、指摘が出るはずだ。
67 万行の diff を上手くできないツールも有るので、いくつかのツールを試し、出力を比較して妥当だと考えられる出力を選ぶ。diff で得られた差分から、ファイル内容を読んでみる。幸い目視で可能な量だった。7 個の破損ファイルを確認し、ダウンロード、あるいは他にコピー元があるファイルだと分った。ここ 4, 5 年は使った実績も皆無だった。
色々と長かった。不良ブロック番号をファイルのパスに変換するツールを探した方が早々に作業は完了したのかも。
2019.10.25 追記
データドライブが壊れた (1) - バックアップドライブも壊れていた
データドライブが壊れた (2) - クローニングが上手くいかない
基板を確かめてみる。12V から 5V に降圧するスイッチングレギュレーターの IN, OUT 両方のコンデンサが高リプルに耐えられるかどうか怪しい。105 ℃規格品なのは確かだ。インダクタも開磁路型なのでノイズ放射が大きい。
ブリッジチップの刻印を読む、JMS567 だ。ファームは何だろうか？使ってみたところ、ランプの点き方は Version 138.01.00.01
かその派生の様に見える。
コンデンサとインダクタを交換する。場合によっては長く使うかもしれない。コンデンサは東信 UTWRZ 25V 220uF に交換、並列に MLCC 25V 10uF Z class、インダクタは準閉磁路型(狭いギャップがある)で同一定数 33uH に交換する。ブリッジ線を入れたのは、部品を外す時にパターンを痛めたので補強した。半田ごてを二刀流で使えばよかったかも。
導通・非導通チェック、基板単体動作で電圧チェックをする。主要な電源ライン 12V, 5V, 3.3V を確認できた。問題なし。
ここまで手を入れた UNI-HAL35 は結局使わないことにした。先の Asmedia ASM1053 を使った 玄人志向 GW3.5TV-SU3/SV と同じ挙動になる。同じようなファイルを読みだしたところで、USB 接続が切れてしまう。ハードディスクに問題が有ると考えた。
先にバックアップ先のハードディスクの不良ブロックマップを出す。これも、実際の作業流れではクローニング完了後に分かる情報だ。
画像をクリックすると PDF を開きます。
先に言及した通り、このドライブは 2016/10 に不良ブロックが発生している。次が 2016/10 時点の不良ブロックマップだ。Zero Fill をして不良ブロックを代替して使い始める(代替すると不良ブロックが消えたように見える)。
画像をクリックすると PDF を開きます。
不良ブロックは近隣にじわじわと広がらず、飛び火する様に広がっていた。この壊れ方ではパーティションを切って使わないようにしたり、fsck.ext4 の -l または -L オプションで拡大的な不良ブロックリストを指定して避けても、効果はない。
USB 接続では安定したクローニングができない。SATA 接続にして、クローニングを行う。データドライブと同様に sg_dd を使用してクローニングをした。不良ブロックの近辺でいわゆる「低速病」になった。16block を読み出すのに 1 ～ 2 秒ほど掛かる状態が 1 日程度続く。途方もなく長い作業を覚悟した。終わってみれば全ブロックをコピーする速度は 23.09 Mbyte/sec だった。
「低速病」の原因の一つは、不良になりかかったブロックのエラー訂正、あるいは何かの条件を変更した読み出しを行ってデータ修復を行う動作なのか。
遅いクローニングに並行して照合作業を迅速に行う方法を調査・検討していた。cmp コマンドで双方のファイルを一つ一つ読み出し byte to byte で比較すると数日では終わらないことが分かってきた。
多少冗長なスクリプト(リンク先はスクリプトのソース) で、一つ一つの md5sum を計算し、パス名を正規化(パスからマウントポイントを削除する), sort, diff を行い差分から、破損、喪失(ないはず) ファイルを見つけることにした。
CDir1=/mnt/sdd3/furuta/backup2nd/whitenine-2nd # path to mount backup root
if [ -n "$1" ]
then
CDir1="$1"
fi
CDir1T="${CDir1}"
if ( ! echo "${CDir1}" | grep -q '/$' )
then
CDir1T="${CDir1}/"
fi
(cd "$CDir1"; find . -name '*') |
while read
do
File1="${CDir1T}${REPLY}"
if [ -d "${File1}" ]
then
continue
fi
sum=`md5sum "${File1}" | cut -f 1 -d ' '`
echo "\"${File1}\" ${sum}"
done
67 万行の diff を上手くできないツールも有るので、いくつかのツールを試し、出力を比較して妥当だと考えられる出力を選ぶ。diff で得られた差分から、ファイル内容を読んでみる。幸い目視で可能な量だった。7 個の破損ファイルを確認し、ダウンロード、あるいは他にコピー元があるファイルだと分った。ここ 4, 5 年は使った実績も皆無だった。
色々と長かった。不良ブロック番号をファイルのパスに変換するツールを探した方が早々に作業は完了したのかも。
2019.10.25 追記
データドライブが壊れた (1) - バックアップドライブも壊れていた
データドライブが壊れた (2) - クローニングが上手くいかない
お気に入りの記事を「いいね！」で応援しよう
[ソフト開発日誌] カテゴリの最新記事
-
Final Data Photo Recovery 9.0 - exFAT … 2024.06.06
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
© Rakuten Group, Inc.
