ディスク復旧に関する小話1

2がないことを信じたいですが...

こちらに補足説明や まとめなどがあります。

以下だら〜っと長い文章が続きます。

_ Librettoの純正のHDDにWindows95を入れて、スマートメディア + PCカードアダプタや PCICの設定を調べてみようということになった。 以前LibrettoにWindows95を入れたときのディスクイメージを PDに保存しておいたので、それをddで書き戻す実験も兼ねていた。

_ 以前のboot-PAO.flpで起動してみたが、mount_nfsが入ってなかったので 失敗。しょうがないので普通のboot.flpで起動して、 PLIPで転送させることにした。

_ mountまではうまくいったんだが、今度はddがみつからない。 インストールでは使わないので仕方ないが。 デスクトップ側でddをソースからコンパイルして (make -DNOSHARED OBJFORMAT=aout)、そいつを実行させる。 (./dd if=libwin95.dd of=/dev/rwd0) しばらく他のことをしつつ 時間を潰して、机に戻ってきてふと傍らの引き出しを開けた。 普段ここにはLibrettoの純正のHDDをしまっておいてある。 今はそのドライブはLibrettoに入ってて、普段使ってるドライブがここに あるはずだが...

_ どうも薄い。はっとなってあわてて確認してみると、 Libretto純正のドライブがそこにあった。ということは 現在ddでイメージを流しこんでいるのは普段つかっているドライブという ことになる。入れ替えるのを忘れていたのだ。

_ あわてて^Cで止めたがもちろん手遅れだ。 はっきりいってここまで間抜けで重大な失敗をしたことは 今までになかったので、かなり強烈なショックをうけている。 現在のおれのこんぴゅーた環境というのは、Librettoのディスクの中のもんに ほぼ全面的に依存している。はっきり言ってLibrettoのディスクの中身がないと まったく仕事にならない。 今思い出せるだけでも

  1. PPP接続とNAT
  2. メールのやりとり
  3. 日記と写真
  4. 自家製Webの読み書き
  5. 過去のメール一式
  6. その他いろんなデータ
あたりがすべて消えてしまっている(完全にデスクトップ1本に 依存しているのはJava環境くらいだ...)。 まあ設定だのメールだのはいいとしても、日記データが消えてしまったのが ほんとに重大だ。 1998年のぶんはデスクトップの方にバックアップが残っているのだが、 99年に入ってからのものと、97年以前のものがどうなっているのかが 問題である。

_ 99年のものでは、3月20日くらいまでの日記は、外に出したものから テキストだけは回収可能だが、それ以降昨日までの日記とカメラの画像などは もうない。 また。97年くらいまでのデータは、PDに保存したぶんがあるかもしれない。

_ ちょっと被害の大きさが想像できない。

_ 実は昨日の夜、フトンの中でHDDが壊れたりデータがなくなるという イメージが浮かんできて、そうなる前にバックアップしとかないと、 と思っていたのだが、その矢先にこんなことになっている。

_ PLIPの速度を考えても、おそらく100MB以上を Windows95のイメージで潰されていることになるだろう。 disklabelなども綺麗に潰されていて、しかも悪いことに今までの disklabelを覚えていない。もしdisklabelだけでも復元できれば、 潰されずに無事なデータを救って来れる可能性もないわけではないのだが。

_ とにかく、現在はどうしたらいいのか考えようもないくらい 意気消沈している(と同時に失ったものの大きさと自分の迂闊さに 怒りすら感じている)ので、この場でヘタに動いて傷口を広げるより、 まずは今後どうすればいいのかを考えてみなければいけない。


_ とりあえず、壊してしまったLibrettoのディスクのイメージを 保存しておくことにした。できれば、とうぶんの間この ドライブはいじりたくないんだけど、ソフト的に解析するなら イメージとして持っておいた方がいいと思うし。

_ しかし、実際問題として解析はできるんだろうか。正直言って 自信がない。でも、このまま放っておくわけにもいかないのである。 このドライブの中にはおれのここ数年の作業の成果が 詰まっているのだ。

_ いや、実際のところ、作業を始める前に きちんとドライブの入れ換えしなきゃいけないと 思っていたのだ。しかし、実際にddの処理に入る前にすることが いっぱいあって、しかもそれが上手く行ったもんだから 少々調子に乗って大事なことを忘れてしまった、というのが真相らしい。 それだけに、我ながら迂闊だったと悔やまれるし、またバックアップを とっていなかったことも今更のように悔やまれる。

_ こんなことが起こる前は、たしかに欝とした気分ではあったけど それでも身のまわりにやりたいことはいろいろあって、 希望なんかも見えたような気がするけど、現在は、この 問題が解決するまでは先に進める気がしないし、 今まで見ていた、先の希望みたいなものがことごとく 色褪せて見えてしまう。 はやく復帰したい。


_ 一夜明けた。昨日は21過ぎにフトンに入ったような気がする。 寝る前に、以前とっておいたLibrettoのWin95環境が復活できるか 試して(つまり最初にやろうとしていたこと)、うまく起動して 使えることを確認した。これでddをつかったバックアップが 有効であることがわかったので、現在壊れ中の1.4GBの ドライブの保存にとりかかった。

_ 2654064+0 records in/out で 1358880768 bytes transferred in 29002.885510 secs (46853 bytes/sec) ということだから、処理におよそ8時間かかったことになる。 とりだしたイメージのタイムスタンプが4:59であるから、まあだいたい その通りの結果である。これは復旧作業も楽じゃないかもしれない。 (ブロックサイズを516096まで大きくできることがわかったので、 それで試せばたぶん5時間弱まで時間を短縮できるとは思うが)

_ しかし、フトンでいろいろ考えたんだが、 上記のように秒間46kで(まあ壊したときとはreadとwriteの立場が逆だから もっと遅い可能性もある)、あのときだいたい20分くらいは作業を続けていたと 思うから、実際に転送されたのは50MB足らずということに なりそうである。で、当時のパーティションのとりかたを 忘れているのだが、たしか最初の方に100MB以上のSWAPパーティションを つくり、そのうしろにroot、次に/varをそれぞれ30MB程度とって、 最後に/usrをとったような記憶がある。 そうなると、slice/partitionさえ復元できれば、データの方は 無傷であるという期待ができないわけではない。

_ 問題は、その正確なスライスの大きさ(ハイバネ用に後ろの領域を いくらか外して確保していたんだが、その大きさ)と、 パーティションの大きさ(とくにSWAPの大きさ)が わからないと復元ができないということだ。 以前、Zinnia MLでここらへんをちょっと流したような記憶があるので、 やややんとかに聞いてみようと思う。

_ あと、バックアップをとってある当時の日記なんかを眺めてみて 情報がないかを探してみるつもりだ。 さらに、デスクトップの方にvnデバイスを入れたので、寝ている間にとっておいた イメージを使って中身を覗くことができるかどうかも調べるつもりだ。 これができれば、本物のドライブをいじらなくても 復元のテストなどができるかもしれない。


_ 学校に行って、やややんとこのチャットで現状報告。 これで、過去メールからLibrettoの設定に関するヒントなどが 得られることを今は祈るしかない。

_ 現状はたしかに絶望的だが、しかしまあ

  1. ufsに関する理解を深める
  2. 本業から一時身をひいて、冷静に考える
  3. 部屋の片付けをする
  4. 現在、それから今後の自分について冷静に考える
  5. バックアップの大切さを知る
  6. 障害時の復旧の技術を磨く
といったチャンスなのかもしれない。 そういうチャンスを得るために起きた事件なのだ。これは神の配剤なのだ、 というような「プラス指向」はおれはイヤだけど。

_ 今まで、小規模なクラッシュだとか、操作ミスからデータを失ったとか そういうことは何度もあったが、今回のはもし本当に復元が不可能ならば PC-9801UV時代から8年以上かけて少しずつ進化してきたデータや 設定などをすべて失うことになってしまう。それだけはなんとか 避けたいところだ。

_ 最終的にはディスクイメージを探りまくって少しでもファイルを 救うことになると思うが、それも実際問題可能なのかどうかは わかってない。過去のslice/partition配置を復活させて うまく元に戻るかどうかということも自信がないし、 そもそもその正確なslice/partition配置を指定できるのかどうかという 問題がある。

_ まあ、そこらへんを操るコマンドの操作方法なんかを調べておいて、 少しずつ手を加えてゆくしかないだろう。実際に書き込みをしなければ 現在以上に症状が悪化することはないと思うし。

_ とりあえず、具体的な行動を起こさず、対策を練るのは 20日(今週の火曜)を期限としておこうと思う。 それでも打開策が見えないのなら、少なくともメール環境だけは 復活できるように、デスクトップ上で設定を始めるつもりだ。

_ Librettoのドライブの方は、ギリギリまで中身を消さずに保持しておくつもりだ。 DSC-X110が来たら、純正のドライブにDebianを入れて、とりあえず 当面は凌いでゆくつもりだ。

_ どんなに時間がかかっても、とにかく/usrが生き残っている確率は かなり高いのだから、あきらめずにサルベージを試みるつもりだ。 そうだ、これはサルベージ作戦なのである。 願かけの(というか慘めさを演出する)意味も込めて、 今日からヒゲを剃るのをやめよう。 ちなみにヒゲは木曜日の朝に剃ったっきりである。ヒゲを剃ってないということは 当然風呂も以下略 (不潔)

_ 少なくとも今週は、新しいカメラも来るだろうし、 就職のゴタゴタ、研究室配属のゴタゴタなどで試練の週となるだろうが、 メゲずにがんばりたいと思う。


_ さて。現在は、今朝のうちにとっておいたディスクイメージを bzip2で圧縮中。もとが1.3GBであったが、もしCD1枚ぶんくらいにまで 小さくなってくれればCDに焼いておいて保存しておこうと考えているんだが... ちょっと厳しいかな?


_ やややんに電話でも調査をたのんでおいたら、1時間くらい後に 電話をくれた。ありがとー(;_;)

_ そこで得られた情報としては、/usrが1116MB、ハイバネ領域が24MBらしい ということだった。

  1. FreeBSDの領域
    1. swap (??MB)
    2. / (32MB)
    3. /var (30MB)
    4. /usr (残り: 1116MB)
  2. ハイバネ用領域 (24MB)
HDDの容量から逆算すれば、FreeBSDの領域と、同時に スワップの大きさが分かるということになるが、 ただどうやってその領域を確保したかが問題だな...当時の領域のとりかたを 忠実に再現しないとジオメトリがずれてしまう。 おそらくハイバネ用領域が24MBといってもぴったり24MBというのではなくて、 先頭にFreeBSDの領域を確保したときに、だいたい24MBが残るような 処理をしているはずだし... ただ/usrの1116MBというのはわりと期待の持てる数字だと思う。 というのも、端数があるということはswapに100MBだとかわりと キリのいい数字をあてていると想像できるからである。

_ なお、イメージ圧縮の方は現在も続いている。もう3時間を越えているようだ。 サイズの方も700MBを越えてしまった。CD1枚に収まるかという おれの望みは脆くも崩れ去る。しかもbzip2は圧縮がとても遅く、 展開もけっこう遅い。圧縮が遅いのはそれほど問題ではないんだが (頻繁に出し入れするならともかく)、展開が遅いのはちょっと問題かも。


_ 圧縮終了。時間は4時間ちょっと、で最終的なサイズは854MBとなった。 うーむ、なんとも中途半端なサイズだ。石垣君とこのCanBe純正のドライブに きっちり収まるか? ...でもやっぱりCDに焼いときたい気がする。


_ 結局のところCD1枚には収まりそうにないので、今後の利便を考えて gzipで圧縮しなおすことにした(だってbzip2展開遅いんだもん)。 時間かかってしょうがないけど。

_ 今日はほんとに久々に運動をしようと思う。なんとなく体のキレが悪いのと、 そろそろ暖かくなってきてフロ入る前に汗を流してさっぱりしたいなあという 気になったからというのと、それから現在の慘めな状態ではいろいろと 考えこんでしまうので、体をどんどん使ってそういうことを 溜めこまないようにするという意図がある。

_ たかがこんぴゅーたのデータでここまでここまでへこんでるとは。よわよわ。 だけどしょうがない。 こんぴゅーたと共に生きると決めた6年前から続くゴウみたいなもんだ。

_ やややんから教えてもらった/usrの大きさにしたがって配置を考えてみた。

  1. FreeBSDの領域
    1. swap (94MB)
    2. / (32MB)
    3. /var (30MB)
    4. /usr (残り: 1116MB)
  2. ハイバネ用領域 (24MB)
うーむ。swapが94MBというのはちょっと半端なような気がする。 100MBとしてとらなかったのかなあ...? 実際問題、ここで1ブロックでもずれるとうまくいかないわけで、 何度も試してみるしかないのかなあと思う。

_ 実際の試しかたとしては、

  1. FreeBSDのブートディスクのsliceエディタ、disklabelエディタを 使ってこれらの値を設定し(もちろんNewfs = N であることに 注意する)
  2. 最小限のファイル(compat1など)をインストールしようと試みる
  3. もし正しくないのならエラーが出て止まると期待されるので、 再び最初からやりなおす
といったものを考えているが、
  1. うまくいかなかったとして、そのときに書き込む場所は MBRとdisklabel保存部分だけで済むのか(つまりデータブロックなどに影響はないのか)
  2. Linuxみたいにswapの初期化をしていないのか。もしswapを実際より 大きくとってしまうと/(root)などを破壊してしまう
  3. 実際問題、正しいデータを書き込むことができるのか。できたとして それで元どおりになるのか
  4. /usrなどの領域が、実際より大きかったり小さかったりした場合どうなるのか 単にfsckなどで怒られるだけで済むのか。もし大きくても許されるなら とりあえずハイバネ領域に踏み込んで確保することで より安全性を高めるという方法がある
  5. バックアップは万全なのか。これがうまくいってなければ 少なくともslice/disklabel書き戻しによる復旧は不可能になる
といった疑問が残る。まあ最後さえクリアされていれば あとの問題は、その都度復旧するという最終手段があるわけで めちゃ時間がかかることを除けばあまり問題ないとも言える。 本当ならもう1台ドライブが欲しいところだが...

_ こうなってくると、今のうちに新しいノートを買うという選択肢も 出てくるな。とりあえずLibrettoにおける環境を 新しく作りなおすという気分にはなれないが、新しいノートで 新しい環境を作るということなら気力が湧いてくるような気がする。 そうすれば、あわててLibrettoの方をいじって潰すようなこともないし。

_ まあ問題なのは、現在手に入るものであんまり欲しいものがないという ことなんだが... とにかく、もう一度探す努力をしてみようと思う。


_ 現在1枚目のdummy write中。gzipしている間に 運動に出た。22時ちょっと前に家を出て、軽く走ったり歩いたりしてから 家に戻ってきたのが2240くらいで、それからsplit -b 620mと mkisofsをしつつ室内で軽く体を動かして、cdrecord -dummyしながら 風呂に入ったというところだ。あと20分くらいでdummy writeが終わるだろう。 終わったら本番を書いて、それから残りを書きながら寝ることになるか。

_ 残りの方は300MB弱なので、余ったところに辛うじて残っている 1998年分の日記と写真を入れて焼いておこうと思う。 これでとりあえず復旧作業を始められるかな。

_ しかしまあ、軽く走って軽く室内で運動しただけなのに、とくに 腿の筋肉が張ってしまって大変だ。やっぱり体力落ちてるんだな。 しっかり運動しよう。

_ 換気のために部屋と台所の窓を開けた。窓を開けるなんて 何ヶ月ぶりだろう。10月下旬ともなれば寒い日が続いていたから、 それっきりおよそ半年ぶりということになるか。 この時間になっても室温は17度もあるし、どんどん 暖かくなってきている感じである。桜も少しずつ咲いてきているし。

_ (23:30) real write開始。dummy writeが35分かかったので、 まあ12時ちょっと過ぎには終わる予定だ。 cdrecord 1.8a20は、今んところなかなかいい調子だな。1.6.1あたりの頃は 開始数秒で死んだりしてたもんだけど。 なお、cdrdaoを試そうと思ったんだがPCCTSを入れるのを忘れていたので できなかった。portから入れりゃいいような気もするが なにしろ現在はダイヤルアップ環境がないしな(;_;) どうせ、CD-DAのデュプリをやろうと思えばcdrdaoの世話になるわけだから まあ今回はCAM + cdrecordの様子見ということにしておこう。

_ (0:22) 2枚目焼き中。あと20分くらいかな。

_ (0:49) 終了。さて今日はこのくらいにして、「FreeBSDカーネル入門」を 読みつつ寝るか。


_ 今まではdisklabel復旧について悲観的に見ていたけど、 おちついて考えてみると、「先頭から何MB」というものだから それこそtry and errでなんとかなりそうな気もしてきた。 それでもだめならsuperblockとinodeをたどってゆけばいいんだし...

_ 現在、CDに正しくバックアップがとれているかを試すために HDDに残っているイメージファイルと、CDから連結/復元したイメージの それぞれのMD5をとっている。さすがにでかいだけあって時間がかかる。

_

_ (9:48) ふむ、MD5は一致してるな。これで少なくとも ddでとったイメージの保存は問題なしといえるだろう。ddでとった イメージをドライブのバックアップとして使えるかどうかは また別問題だけど...まあ以前とったWindows95でもうまくいってたし、 コマンドラインもきちんと確認したし、よしということにして 先に進むか。

(10:08) いきなり間違えた。newfsしてしまった。しかたないので イメージからドライブに復元である。ほんとバカだなーおれは。これで 5時間のロスである。


_ 百田屋でさかなフライ定食を食って戻ってきた。 学校では、連絡用Webをあげて、ノートパソコンの調査をして、 さらに障害復旧に関する情報の収集をした。

_ 障害復旧のやりかたとしては、だいたいおれがこれからやろうとしていることと 同じようなことをやっているみたいなので、まあおれの 方向性は間違ってなさそう。ただ今回のケースで図にあたるかどうかは まだわからない。

_ で、一度家に戻ってきたわけだが、まだddは終わっていない。あと 1時間以内には終わると思うんだが。それと、郵便も来ていなかった。 DSC-X110、そろそろ来てもいいころなんだけど。 納期は、「入金確認から5日(土休日除く)」とあって、 入金確認は、15:00までに済ませていればその翌日にされると書いてあったはずだ。 入金したのが13日(火曜日)の13時くらいだったから、翌日に確認されたとしたら 今日が納期ということになる。「土休日除く」というのは、 5日のカウントから除くということなのか? そうなると 納期は明日ということになる。まあどっちにしろ、今週中に込ないようなら 連絡しなきゃ。

_ さて、これから本屋にちょっとでかける予定。戻ってきてから復旧作業を始めて、 16時過ぎに学校に戻るつもりだ。今日は研究室配属が最終的に決まって さらに呼出し日時なんかも決まる日であるから、その確認をすることになる。


_ 本屋に行ってきた。いい機会なので「386BSDカーネルソースコードの秘密」を 買おうかと思ったんだがファイルシステムに関する話題はなかったので ちょっと買えなかった。まあいずれ買うことになるとは思うけど。

_ 今月のSoftware Designもなかなかよさげ。あとで生協で買っとこうっと。

_ 昼過ぎから雨がときどきぽつぽつと降っているようだが ほとんど気にならない程度。空も薄暗いものの、これから崩れるという 感じはしない。天気予報を見ても、向こう1週間は大きく崩れることは なさそうだ。

_ (16:22) dd終了。2633+0 records in/out (on bs=516096)で、 1358880768 bytes transferred in 17997.827999 secs (75502 bytes/sec) ということだった。5時間というところか。ほぼ計算通りといいたいところだが、 ddを開始したのが10:30より前だったと思うので、そっから計算すると 6時間かかったことになる。どうなってるんだろう

_ すぐに復旧作業を始めたいところだが、まずは学校に行かねばいかんので ここで中断。


_ 学校から戻ってきた。 まずは兼ねてから書いておいたとおり swap 94, root 32, /var 30, /usr 1116 で試してみる...失敗。 どんどんやってゆこう。

_ (17:02) swap 95 (/usr 1115) 失敗。 Newfs=Nだけは注意しないとな。

_ (17:05) swap 96 (/usr 1114) 失敗。

_ (17:08) swap 93 (/usr 1117) 失敗。

_ (17:12) swap 92 (/usr 1118) 失敗


_ ちょっとかったるいので中断。タッチとおじゃる丸を見た。 うーん、今日のおじゃる丸は久々のヒットだった。オープニングから いきなり笑わせてもらった。やっぱり電ボが絡むと面白い。

_ さて上記のgeometry復旧だが...やっぱり闇雲にやってもダメなような 気がする。せっかくイメージを取得してあるんだから、 こいつを見ながら(デスクトップのものと比較しつつ)正しい配置を 調べる方がいいような気がしてきた。 それで復旧できればいいし、できなくても今後手動で取り出すときの 前準備にもなる。

_ 生協でおかいものをしてきた

_ そうそう、研究室は小林研究室・樋口研究班に決まったようだ。 明日の13時に集合らしい。樋口研究班は、 現役が3人(女性2人、男性1人)、Bコース男性1人、で留年生がおれ、 さらに院生なんかがいるらしい。といっても結局のところ 小林研究室と設備なんぞも共同だったりするらしいし、なんかな。

_ 現在のところ、なにもかもがうっとうしくて嫌になっている(というのは 別にLibrettoがピンチなのとは無関係だ)が、まあ腐らずに先に進む努力を しよう。


_ 走って部屋でちょっと運動して風呂入ってきた。今日は室内の温度は 昨日とそれほど変わらないが(多少今日の方が高い)、外は 昨日よりだいぶ寒かった。 足と腕、腹筋にそれぞれ筋肉痛を覚えていたのでわりとつらかった。 とくに足はけっこうきついな。

_ 復旧のための作業はまだ実際のところほとんど進んでいないが、 慎重に進めたいのでそれもまたいいだろう。 メールの環境だけでもデスクトップ上でできるように 明日のうちに設定をするつもりだ。

_ さて、ディスクやファイルシステムに関して現在わかっていることをまとめておく。

  1. ドライブはスライス(DOSではパーティション)に分割されている
  2. MBRはドライブの先頭512バイトに存在する
    1. スライスに関する情報(start/end/OS/bootableなど)
      1. 1つのスライスについて16byteの領域があり、その中身については
      2. struct dos_partition(sys/sys/disklabel.h)のようになっている
      3. それらのスライスからbootさせるためのプログラム(ブートローダ)
ここまではドライブに関する話。以下はFreeBSDのスライスの話
  1. スライスはブロック(512バイト)単位で扱われる
  2. スライス内部で複数の区画(パーティション)を作ることができる
  3. ブロック#0 にはブートプログラム(カーネルを読み込むためのプログラム)の 最初の512バイトが収められている。
  4. ブロック#1 にはパーティションに関する情報(disklabel)が収められている。 内容についてはstruct disklabel(sys/sys/disklabel.h)を参照
  5. ブロック#1〜14は、ブートプログラムの残りの部分が収められている。
  6. ブロック#1は、disklabel領域であると同時に、ブートローダの初期値あり データ領域でもある
  7. ブロック#15 は未使用
  8. ブロック#16 から実際のファイルシステムが構成される
以下はパーティション内の話。
  1. パーティション内部はi-nodeとデータブロックに分けられている
    1. i-nodeはファイルやディレクトリに関する管理情報をもち、固定長
    2. データブロックは、それらファイルやディレクトリの中身が保持される
  2. i-nodeとデータブロックの開始位置と長さ(どちらもブロック単位)を記録した スーパーブロックという16ブロック(8KB)の領域を持つ
    1. FFSでは、まずブロック#32から置かれ、さらに 複数のバックアップを作る。どのように作られているかは src/sbin/newfsあたりを見ればよいし、 また newfs -N とすれば実際に書きこまれるブロック番号を 知ることができる。(うちの8GBドライブの/(root)は 64KB(註: 64Kブロック = 32MB の誤り)おきにバックアップを 作っているようだった) スーパーブロックには、それ自身がスーパーブロックであることを 示すためのマジックナンバー(FS_MAGIC = (int32_t)0x011954 @sys/ufs/ffs/fs.h)を持つ。
  3. i-nodeは固定長のエントリのため、先頭から番号をふられている
    1. /(root)はi-node番号#2に収められている
    2. i-nodeにはファイルやディレクトリに関する情報が与えられており、 通常はstatシステムコールでその中身を見ることができる
    3. 記録されている形式は、struct dinode(sys/ufs/ufs/dinode.h)を参照
    4. ディレクトリは、その中身のファイルとi-nodeの対が 可変長(ただし4の倍数)で格納されている1つのファイルと見ることが できる
  4. FFSの場合は、パーティション内を複数のシリンダグループに分割し、 同じディレクトリのファイルなどがなるべく同じシリンダグループに 属するようにしたり、それぞれのシリンダグループごとにi-node領域と データ領域を置いたり、などということをしてスピード向上を計っているが、 基本的なアクセス方法は古来のUFSと変わらない。
  5. ファイルシステムのいじりかたについては、 sys/i386/boot/biosbootの中身(disk.c, sys.cなど)や newfs、fsckなどのソース、それからもちろんsys/ufs以下を 参考にするといいらしい。
といったところである。

_ とりあえずこれからの手順などを書いておくと

  1. スーパーブロックにはMAGIC NUMBERがあることを利用し、 ディスク全体をscanしてスーパーブロックの候補を選びだす
  2. スーパーブロックのコピーは規則的に並んでいるという性質を利用して パーティションの分かれめ(つまり最初のスーパーブロック)を探す
  3. そのスーパーブロックは#32であることが期待されているので、 そこから逆算してパーティション情報を再現する
...というのが、まず今までやってきた、「インストーラを使って slice/partition情報を復元する」ための最後の作業となる。

_ もしこれで復元がうまくいかなかった場合(といっても 上記の手順はきちんと終わっていることが必要なんだけど)、

  1. スーパーブロックからi-nodeテーブルとデータブロックの位置とサイズを知る
  2. i-node #2からどんどんファイルを辿り、データを拾ってくる
といった処理をして、力づくでファイルを復元する処理をすることに なると思う。この場合は、FreeBSD自体は死ぬことになるが、 まあ大事なデータさえ残っていればほとんど問題ないと考えるべきだろう。

_ まずはメール環境を復活させて、Librettoの復旧を根気よくやることにしよう。 といっても、できれば今週中には仕上げたいとは思っているが...


_ カメラ到着。ものすごいでかいぷちぷちに囲まれていた。 さっそくいじり倒したいところだが、することがいっぱいあって さらに心情的にもそれどころじゃないので、軽く触った程度で 他の作業をする。することいっぱいあるよなあ。


_ 今回もペリカン便だったが配達員のおじさんはとても愛想がよく、 おれ内での日通株はどんどん上昇中。 郵便局とヤマト運輸はもう どん底だけど :-)

_ メールの設定を復活し、溜まったメールを落としてきた。 臨時のアカウントを作って(IDはchinami :-))、そこで設定することに。 なるべく本物(zinnia)の方に手をつけたくなかったので。

_ ダイヤルアップ環境の方は、いちいち設定するのが面倒だったので、 ppp(8)からtermコマンドで手動接続している。 電話番号とかDNSアドレスとかを調べるために、 Librettoのディスクイメージをstringsにかけてgrepした。 ちゃんとデータとしては残っているんだよなあ...

_ 谷村さんからnew-bus以降のcurrentに対応するためのパッチをいただいたので、 こいつを学校に持ってって置いておかなきゃならん。 今から学校に行けば、まあ13:00の呼出しには十分まにあうだろう。


_ 顔合わせ終了。

_ 輪講というのは、海外の論文とか文献を読んで訳すもんだと思っていたのだが、 ここの場合は日本語の教科書をページを分けて読んで解説するとかなんだとか。 5/18から始まるそうで、第一回はおれらしい。何をすればいいのかいまいち わからんけど。

_ その後、簡単な説明を受けて輪講で使うテキストの配布だの、 下駄箱だの(場所ないのでおれ置けないんだけど)を決めたりしたり。

_ コピー室で井藤君に出逢う。市村研究室の院生になったそうだ。 荒井君といっしょだな。昨日は計算機室で伊藤君と会った。 こちらは学部のときといっしょで平中研究室にいるみたいだ。

_ なんかおれ、この先だいじょうぶかなあと早くも心配になってしまった。 最近のおれはどうも自信がなくていけない。別におれの好きに やっていればいいのに。


_ ディスク解析開始。まずはデスクトップの正常に動いているドライブ (現在使っているやつ)を相手に、いろんなソースを眺めつつ、しかし闇雲に 解析をしてゆくと、ブロック中、offset 348からの4バイトに MAGIC NUMBERがlittle endianで入っているらしいことがわかった。

_ その条件でscanしてみると、たしかにSuper Blockは全部ヒットしている みたいだが、他にもいくつかヒットしてしまった部分があった。 しかし「同じパーティションのSuper Blockならみんな同じだろう」という ことで、最初にとったスーパーブロックのデータと比較して、 同じでないものを弾いてみたところ、きちんとスーパーブロックだけを 取り出すことができた。

_ ただし、スーパーブロックのあるブロック番号が、34、65570....などと newfs -Nで帰ってくる値と比べると2だけ大きいというのがちと気になる。 /dev/rwd0a を相手にしているのがまずいのか、しかし他に適当な デバイスなんてないし。 まあとりあえずはそれほどの問題でもないので無視しておく。

_ ここまでできれば、実際に壊れたイメージを相手にした戦略としては

  1. ブロックを最初から最後まで嘗めて、Magic Numberが一致するものをリストアップ
  2. それらの候補について、identicalなもの同士をまとめてハッシュのようにしておく。そうすると
    1. 同じのがたくさんあってしかもstepが65536とか一定のもの: 数個
    2. 同じのがほとんどないもの: けっこうたくさん
    というデータがでてくると期待されるので、 そこから正しいslice/partitionの関係を見極める
というところになるだろうか。 scanのプログラムだけでも書いておいて動かしておきたいところだけど、 あと1時間後には集合だしなあ。くそーめんどくせーからフケちまおうか。


_ 帰還。疲れた。

_ 飲み会は、結局ゼミで利用する教室でおこなわれた。おれはなんだかんだで 樋口先生の隣に陣どることになった。 最初はWaveletの話題なんかを喋っていたのだが、結局のところ就職の話になる。 そういうもんなのかねえ。 後から小林先生もやってきていろいろ喋る。小林先生は今年の就職担当だそうで、 そこらへんの話題を追及される。

_ 実験(MS-DOSとアセンブラ)のときに世話になった田中先生とUNIXまわりの話をしたり。 しかしあの先生はよく飲むなあ。よっぱらって喋りまくってた。 さらに近くに座っていたG田中さんとも喋る。もう在学期限ぎりぎりまで 留年を続けていて、今年卒業できないと退学になってしまうとか。 年期入ってるなあ。おれなんて、院生を見るとたいていは 実験なんかで見た顔がいて、それはそれでやりにくいところはあるけど。

_ 酒は、それなりに入っているが、まあなんとか頭が周る程度には 抑えておいた。のでこれからディスク解析の続きをするつもりだ。 今日は運動はムリかなあ。疲れてはいないけど、酒がまわっているので 走ったら大変なような気がする。

_ 明日は、天気もいいことだし、DSC-X110の実力テストも兼ねて 霞城公園の桜でも撮影しに行こうかなあと計画している。 まだわからんけど。


_ 作業は続いている。現在の成果としては...

Input file is libdisk.dd.
*** SUMMARY ***
45 matched out of 2654064 blocks.
case 1: 2 entries.
 32865 (131072) 163937
case 2: 43 entries.
 243793 (16) 243809 (65536) 309345 (65536) 374881 (65536) 440417 (65536)
 505953 (65536) 571489 (65536) 637025 (65536) 702561 (65536) 768097 (65536)
 833633 (65536) 899169 (65536) 964705 (65536) 1030241 (65536) 1095777 (65536)
 1161313 (65536) 1226849 (65536) 1292385 (65536) 1357921 (65536) 1423457
 (65536) 1488993 (65536) 1554529 (65536) 1620065 (65536) 1685601 (65536)
 1751137 (65536) 1816673 (65536) 1882209 (65536) 1947745 (65536) 2013281
 (65536) 2078817 (65536) 2144353 (65536) 2209889 (65536) 2275425 (65536)
 2340961 (65536) 2406497 (65536) 2472033 (65536) 2537569 (73606) 2611175
 (15416) 2626591 (2272) 2628863 (8336) 2637199 (1644) 2638843 (32) 2638875
なんともナゾな結果になってしまった。

_ 今後の対策は

  1. そもそもプログラムが正しいかどうかを検証する。とくに比較のあたり
  2. 現在はoffset決め打ちになっているMAGIC NUMBER比較部分が正しいかどうかの確認
  3. 実際に、純正のドライブで領域をつくってみて、どのような結果になるのか
  4. 見定める
とりあえずはこんなところだろうか。しかしパーティションごとに スーパーブロックが一緒なんてことになっていたら、この作戦は そう簡単には実を結ばないような気がする。先は長いかもしれんなあ。

_ また、今までなんで気付かなかったのかなあと思っているのだが、 LibrettoのHDDイメージの中から、スライスに関する情報を抽出するために 努力している(/etc/dailyのメールの中身とか...) 今んところ 有望な情報はみつかってないんだけど。

_ 過去の日記を見ればわかるかもしれんのだが、日本語はstringsには ひっかかってないと思うので厳しいかもしれない。


_ 寝ようと思ったら猛烈な空腹を覚えたので起きて食事。 すぐに寝るわけにもいかんので作業の続きをした。

_ とりあえず純正のドライブにFreeBSD 2.2.5-RELEASEを入れて、

  1. swap 28MB
  2. /(root) 32MB
  3. /var 30MB
  4. /usr 118MB
というようにpartitionに分けて、解析プログラムにかけて 調査してみた。
*** SUMMARY ***
18 matched out of 530208 blocks.
case 1: 7 entries.
 32865 (131072) 163937 (65536) 229473 (65536) 295009 (65536)
 360545 (65536) 426081 (65536) 491617
case 2: 11 entries.
 57425 (16) 57441 (65520) 122961 (16) 122977 (61424) 184401 (16)
 184417 (65536) 249953 (65536) 315489 (65536) 381025 (65536)
 446561 (65536) 512097

_

  1. case 1の方はSWAPの領域内部のものであるため今回は無関係
  2. case 2の方はそれぞれ/(root)、/var、/usrのスーパーブロックのようだ。 本当のdisklabelと照らしあわせてみると、
     [/(root)開始] (16) 57425 (16) 57441
     [/var開始] (16) 122961 (16) 122977
     [/usr開始] (16) 184401 (16) 184417 (65536) 249953 (65536) 315489 (65536)
                381025 (65536) 446561 (65536) 512097
    
    といった具合になるようだ。解析プログラムの返してくるブロック番号と、 newfsやdisklabelで帰ってくるブロック番号との間には65のずれがあるようである。 たとえば/(root)のブロック開始は上の表では 57425 - 16 = 57409だけど、 実際は 57409 - 65 = 57344 というぐあいだ。

_ 上記の実験から、

  1. ブロック#32から64Kブロックおきに配置する
  2. 間隔が65536でないところは切れ目の候補、さらにその次が16だったらほぼ確定
  3. ブロック#16に配置するのはufsとの互換性のためと思われる
  4. swapもスーパーブロックと同じマジックナンバーを持つ領域が あるようだ
といった推測ができる。

_ で、

Input file is libdisk.dd.
*** SUMMARY ***
45 matched out of 2654064 blocks.
case 1: 2 entries.
 32865 (131072) 163937
case 2: 43 entries.
 243793 (16) 243809 (65536) 309345 (65536) 374881 (65536) 440417 (65536)
 505953 (65536) 571489 (65536) 637025 (65536) 702561 (65536) 768097 (65536)
 833633 (65536) 899169 (65536) 964705 (65536) 1030241 (65536) 1095777 (65536)
 1161313 (65536) 1226849 (65536) 1292385 (65536) 1357921 (65536) 1423457
 (65536) 1488993 (65536) 1554529 (65536) 1620065 (65536) 1685601 (65536)
 1751137 (65536) 1816673 (65536) 1882209 (65536) 1947745 (65536) 2013281
 (65536) 2078817 (65536) 2144353 (65536) 2209889 (65536) 2275425 (65536)
 2340961 (65536) 2406497 (65536) 2472033 (65536) 2537569 (73606) 2611175
 (15416) 2626591 (2272) 2628863 (8336) 2637199 (1644) 2638843 (32) 2638875
これをもう一度考えなおしてみると.... 243793 - 16 - 65 = 243712がpartitionの開始であることはほぼ間違いないと 思われる。先頭からのオフセットで119MBぴったりというところからも そう思う。が、どこまでがひとつづきの領域なのかは ちょっとよくわからないので保留。 かくなる上は...case 2に該当する43個のエントリから、MB単位で きっちり割切れるものをピックアップしてみるか。

_ 結果は

  1. エントリがブロック#16だと仮定した場合: 最初の1つだけが割切れた
  2. エントリがブロック#32だと仮定した場合: 最初の1つと、最後の6つを除いて すべて割切れた
ということになった。考えてみれば、64Kブロック間隔なんだから 最初さえぴっちりしていれば割切れて当然ってことになるな。 割切れないということは64Kブロック間隔でないということであって 最後の6つが該当しないのはわかりきっているので、 最初っから調べる必要はなかったのかもしれない...

_ ただ、ステップが64Kブロックな部分に仮に複数のpartitionがあったとすると、 ufs互換のための#16が存在しないことになって矛盾するな... ということはひとつのpartitionだと考えるべきなんだろう。

_ また、チェックすべき部分がさらにある。

2537569 (73606) 2611175
ここだここ。もしこの部分をまたがってpartitionがあった場合、 newfsすれば
2537569 (65536) 2603105 (8070) 2611175
といった感じになるはずだ。となると、(解析プログラム表示で)2537569以上、 2603105未満、32MBの範囲にpartitionの切れ目があるということになる。 そうなると、その後ろの領域は、40MB±16KBということになるが、 後ろはハイバネ用領域で、記録が正しければ24MBとっているはずだから... 2603105ぴったり? さっきは未満と書いていたが、以下は条件に あてはまるかなあ。まあ実際に試してみればいい話だが。

_ 少なくとも、開始119MBから1271MBくらいまでに領域があるのは 確かなので、そこから試してみるかな。

_ (4:01) うう眠い。なんでおれはこんなにがんばっているんだろう。 ノってるからしょうがないのか。

_ さて早速119MBから1271MBを確保するようにしてみたところ、 少々の前進。fsckをかけて動作するようにまで行った。 last mounted on /usr になっていた、ということは、 やはりその前に/(root) と /varがあったということになるな。 今から配置を考えてみると、

  1. SWAP 57MB
  2. /(root) 32MB
  3. /var 30MB
  4. /usr 残り
という感じかなあ。

_ (4:05) やはりrootとかの復元は難しそうだ。少なくとも/usrは 無事なんだから、これでよしとするべきか。

_ (4:27) なんとか/usrの中身は復活できそうだ。現在PLIPによる転送中。 諸々のツールはzion側に入れたLive File SystemのCDを使った。 やっぱり便利。

_ で、「(cd / ; tar zcfp - hdd/) | tar zxvfp -」などとして転送中。 まあ、ownerとかpermissionなどにはいろいろ矛盾が出てきそうだが、 コマンドまわりはどうせインストールしなおすんだからそれほど問題でも ないだろう。

_ /etc以下、とくにpppやDNSに関する設定が復元不能だと ちょっと厳しいが(あとでイメージを直接あたってみるつもり)、 /usrが戻っただけでもよかったと思わなきゃな(25分前に同じこと言ってるやんけ)

_ とにかくこれでLibrettoの方も少しずつ回復に向けて作業を始められるだろう。

_ こんな時間まで起きて作業をしてしまったので、山形行きは明日になりそうだな。 今日は、身のまわりのことをやることにしよう。せっかく天気いいのに もったいないけど。

_ そうそう、純正ドライブにFreeBSD入れたついでに、DSC-X110附属の スマートメディアとPCカードアダプタで状況が変化するか試してみた。 結果は今までと一緒だった。

_ 他にもカメラまわりに関して書きたいことはたくさんあるんだが、 今回のところはキリがなくなりそうなのでやめておこう。 また腹もへってきたし...

_ /usrが復活すれば、当分のあいだ純正の方を特別な用途で いじる必要がなくなるので、Debianを入れてPCカードの読み取りに備えようと 思う。これでようやく実用体制だなあ。寝て起きたら、Librettoの復活した ドライブの方にFreeBSDを入れて(3.1-RELEASEにするか?)、 少しずつ設定を戻して、さらにDebianを入れて、カメラの 保存の体制をたてなおしたいところだ。

_ おっと、その前にバックアップも忘れずに :-) 今回はバックアップについても真剣に考えるぞ。

_ (4:44) うわーいやな数字だー(バカ) もう外はかなり明るくなっている。 うーむ、頭はまだ使いものになるが、どうも気分が悪くてしょうがない。 ていうか、飲み会とやらの最中からずっと気分は悪かったんだけど。 やっぱりああいうのは悪い酒だ。特別に量が多かったわけでもないのに、 ここまで胃を重くさせるとは。

_ 転送はおそらく4、5時間がかりになると思われるので、 ぼちぼち寝る仕度をしようかなと思う。


_ 起きた。9時に起きてうとうとしつつ音楽を聞いて目を覚ます。 われながらよく起きられたもんだと感心している。

_ コピーの作業はまだ続いている。けっこう長いな。zつけたのは失敗だったか?

_ ヒゲも剃ってすっきりさわやかである。軽くめし食ってから 写真屋でも行こうかな。 予報通り、外はすげーいい天気で山形に行けなかったのが 少々勿体ないが。

_ 今日はなるべくしっかり寝て、明日こそは山形行こうと思う。 考えてみれば、もうすぐ月末だ。宇都宮旅行がすぐではないか。 ここ2週間くらい電車をまったく利用していないし、リハビリのためにも いろいろ行かないといかんだろう。


_ 写真屋に行ってきた。仕上がりは23日の昼過ぎだそうな。

_ そりゃあもういい天気だ。しかも桜が満開。上杉公園なんか 素晴しかった。平日にもかかわらず観光客がたくさんいて、写真とりまくってたし。

_ なんか、このまま過ごすのは勿体ないなあ。手近なところでおでかけしようかしら。


_ 転送終了。結局10時間かかってしまった。まあいくら時間がかかろうが 中身さえ手に入ればまったく問題ないけど。

_ 外はあいかわらずいい天気なのだが、さすがに眠気が少しずつ 襲ってきていて動きまわる気になれない。 幸い明日もいい天気だそうなので、明日に備えるということにしておこう。

_ さて、/usrの復活が終わったところで、Debianのインストールでもしようかなと 思う。


_ ここから従来通りの環境で日記を書くことができるようになった。 写真屋から戻ってきてから、ちょっと学校で事後報告なんかをして、 さらに百田屋で昼ごはんをたべて戻ってきた。

_ まずは純正ドライブにDebianを入れた。 デスクトップにドライブを繋げてのインストールはもう何度もやったので まったく問題なく終了。以後しばらくはDebianのためのドライブに なると思う。

_ 次にFreeBSDを本命のドライブに入れた。 どのバージョンを入れようか悩んだが、今更2.2.5-RELEASEを入れるのも シャクなので3.1-RELEASEを入れてしまった。 2.2.5-RELEASEが普通に動いている状態だったら、3.1-RELEASEはわざわざ 乗り換えるほどのものじゃないんだけど。

_ 現在のところ、$HOMEの復活と、アプリケーションのインストール、 apacheの設定などを済ませて、とりあえず デスクトップから利用している分には矛盾がない程度には 組みあがっている。

_ あとは、外に出るための環境を整えるくらいだな。 natdの方はもう終わっているので、あとはpppdとnamedである。 namedは、やっぱり必要なのかなあ? natdがうまいこと中継してくれれば いいんだけど。ちょっと試してみようっと。

_ Debianを入れてようやくDSC-X110も本格的な利用ができるようになった。 でも、この日記にのっけるにはシステムに手を入れないとだめかもしれない。 ちょうど改良の時期だし、がんばってみよう。

_ カメラの感想とか、バックアップの話なんかもしたいんだが、 とりあえずもう寝ようかな。今日はほとんど寝てないくせに 妙に元気だな。



戻る
Zinnia (zinnia@risky-safety.org)