解析 / サーバーダウンから復旧まで(4)

投稿日: 2005年09月19月
更新日: 2017年07月22月

解析

ここ数日は解析と解析結果のドキュメント整備がメインのお仕事。

単純なコードだから解析はあっという間に終わるんだけど、ドキュメントの整備に時間がかかる。反省点だ。

それはそれとして、改めて解析をやっていると1年間の成果というか、去年の今頃に比べると格段に理解力が早い。理由としてはいろいろ考えられる。

  • 前にも同じ人のソースを読んだことがあるから癖がわかる。
  • 扱うデータ形式を理解している。
  • 言語(C/C++)に慣れてきた。
  • ソースを読むことに慣れてきた。既知のアルゴリズムしか使っていなければ数千行くらいなら読めるという自信がついた。

これらは応用が利くだろうか。4番目の「ソースを読むことに慣れてきた」のは応用が利く。他の言語や状況においても役に立つと思う。ただし、「既知のアルゴリズム」のレパートリーの少なさはなんとかしないと。

が、1,2番目は汎用性がない。扱うデータ形式も初めてでソースを書いた人のことも知らない状況においてはそれなりに時間がかかると思う。今後そういう状況になったときはその辺を意識しながら見込みを立てていきたい。

それから、僕がアナログ人間だからなのかもしれないが、解析はやっぱりソースを印刷して紙で確認しながらのほうが効率が良い。正確には手元に紙を置いて画面でタグジャンプを使う。

サーバーダウンから復旧まで(4)

前回から間が空いてしまった。面倒なのでざっと。

データの救出に関して。fsckした場合、整合の取れないi-nodeはlost+foundというディレクトリに一旦退避される。今回で言うと、ドキュメントルートのディレクトリが丸ごと消えていたわけで、ここにいくつかのファイルあるいはフォルダが格納されている可能性がある。

で、Knoppix3.7を使用し、SAMBAで共有をかけてWindowsマシンに一旦lost+foundの内容をコピー。大量のフォルダとファイルの中から(リネームされているためどれが何のファイル/フォルダなのかわからない)ドキュメントルートらしきフォルダを探す。フォルダサイズから判断すると簡単に絞り込めた。

ちなみに、このときちょっとだけまずいことを2つやっている。1つ目はSAMBAで共有するときに読み取り専用にしなかったこと。適当にKnoppixから「OK」を押したら読み書きできるようにマウントしてくれたらしい。2つ目はそのままWindowsにコピーしたこと。本来であればいろいろ属性やらなにやらも残しておきたいからアーカイブにでもしておくべきだ。まぁ、どっちも今回はドキュメントルートさえ救出できればよかったので気にしないけど。

名前:宮内 はじめ

Code for Nagoya名誉代表

E2D3名古屋支部長

プログラマーです。GISやデータビズが好きです。このサイトは宮内の個人的なメモです。

プロフィール

お問い合わせ