本日はお昼から高槻にお出かけ。こちらのお店のネットワークがうまく動いていないみたいで、なんちゃってVPN もメールもWebも全滅なのだそうです。心当たりとしてはワタクシが設置したFreeBSDルータの ppp がコケてるかnamedがコケてて外と通信できないことかな～。ここのお店には面倒を見れる人は居ないので電話連絡でFreeBSDの強制再起動(^^;)とADSLモデムの再起動してもらったけれど復旧せず。仕方無しにのこのこ出かけることになりました。

さて、私製ルータなのでそんなに堅固にできてるわけがなく、些細なことでコケる可能性が高いので、これまた些細な作業で復旧させて引き上げるつもりだったのですが・・・。行ってみると HDD が壊れてました(汗)。モニターを繋いで画面を見ると、ブート途中で例の

/kernel: ad0s1e: hard error reading fsbn xxxx of xx xx-xxxx (ad0s1 bn xxxxxx; cn xxxx tn x sn x) status=59 error=40

というのが表示されて固まっておりました。合掌。それで、とりあえずどんな様子か見てみようと思ったのだけれど、なんとキーボードが無い(^^;)。そこらへんに転がってるパソコンは全部USBキーボードですし、確か前に置いて帰ったはずだけれど どこかにしまいこんだか捨てちゃったかしたらしい。うむむむ、これでは手出しができないし、明らかにHDDは不良なのだから部品を調達しなきゃいかんし、HDDだけ取り外して一時退散することにしました。

で、駅までてくてく歩いていこうとすると、なんと目の前にパソコン工房があるんですね。いやはや、これには笑いました。元々付いてたHDDは30GBでしたので40GBのハードディスクと500円のキーボード(これまた安いのが売っていた^^;)を買って作業開始です。

幸い、'/' スライスには不良セクタが無いらしく強制電源OFFの後始末 fsck も正常終了しましたから、ここから起動して新しいHDDに移行できそうです。

まずは何も考えずに新しいハードディスクを接続して

# dd if=/dev/ad0 of=/dev/ad2

を実行。結果はさんざん待たされた挙句 途中で不良セクタにぶつかって終了しました。冷静に考えればあたりまえですね(恥)。

で、man dd と過去の経験を駆使して 今度は

# dd if=/dev/ad0 of=/dev/ad2 conv=sync,noerror bs=512 count=60036480

としてみました。このままほっとけば終わるはずなのですが、すぐ上の操作でエラー終了したときは 転送結果は1.7MB/sと書いてるのですね。ハードディスクは30GBですから、単純に計算すると今から5時間ぐらいかかる計算になります(笑)。これはたまらんということで作戦変更。ブロックサイズをもっと大きくしてみることにしました。さらに先程コピー済みの不良セクタまでのブロックはすっ飛ばしましょう。

# dd if=/dev/ad0 of=/dev/ad2 conv=sync,noerror bs=8192 seek=375000 iseek=375000 count=3377280

---

bs ← 読込み・書込みのブロックサイズ。これを変えると seek/iseek/countも変える必要がある
seek,iseek ← スキップするブロック数。先程は セクタ6000352でエラーがでたので、6000352 / (8192/512) = 375021.999 ということで 375000 を採用
count ← ディスク全体は 60036480セクタだったので、 60036480 / (8192/512) - 375000 = 3377280

なんとか1時間強で終わりました(^^;)。この作業では不良セクタ部分も bs=8192 で走っていますから、最後に不良セクタ付近をbs=512でコピーして終了です。容量の大きいハードディスクへの移植で空き容量を増やす必要が無い場合は簡単でよいですね。ちなみに、ディスク全体のブロック数を知る方法がよくわからなかったので /stand/sysinstall のパーティションエディタで表示された値を使ったのですが、後から考えたら下の合計値でも良いみたいですね。

The data for partition 1 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 63, size 60036417 (29314 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 15/ sector 63

ついでに、後から bs の最適値をさぐるために値を変えながら測定したのですが、bs=64k を超えたあたりからほとんど変化しなくなりました。不良セクタが存在するがそれほど多くない場合には

1. bs=64kにてコピーする
2. そのときに画面に表示された不良セクタの場所をすべてメモる
3. bs=512で不良セクタ付近をコピーする

というのが一番早く済みそうな気がします。

なんてことを後から参考になるようにだらだら書いていますが、本当は参考にする事態が発生しないのがありがたいですね(笑)。

# 上記は1セクタ = 512 バイトという前提で書いています。ATAでもデバイスごとに変わるのかな? カーネルのエラーメッセージは物理セクタかもしれないのでSCSIとかでは当てはまらないかも。
## 不良セクタは前後セクタの中身から連想すると squid のキャッシュ領域だったと思います。セクタ番号がどのファイル/ディレクトリで使われてるかってのはどうやったら調べられるのだろう?

□ 関連記事

• 2005/01/27 会社ルーターが死んだお話 ≪
  • 2005/01/29 もうひとつの障害復旧方法