適当に再起動を繰り返したことが引き金となったのか、/に割り当てていたファイルシステムをマウントできない自体に陥った。あわてずに、UbuntuのCD-ROMをブートすると、そのHDDは不良セクタがいっぱいで危険！とのメッセージが表示された。

とりあえず、マウントしようとしてみるとファイルシステムエラー。
reiserfsなので、reiserfsckをかけると不良セクタによるダメージで問題があるとのメッセージが表示された。

不良セクタを指定してfsck

badblocksによって検出した不良セクタの位置をfsckに渡してやることで、それを避けた状態にできるようだ。

-vを付けると進捗が表示される。
-bでブロックサイズを指定。いまの標準は4096の様だがファイルシステムの作成時期が古い場合など違うこともあるので、なにかで確認すべし。
-cで一度に読み取り、テストするブロックの数を指定する。ある程度多くても問題ないと思うし、適度に大めにすることで速くできそう。
これで数時間。
で、不良セクタ指定でfsckをしてみる。

すると、、ジャーナルの部分に不良セクタがあって死亡(´･д･`) 。。

ddrescueでイメージとしてパーティションを救出

あきらめかけていた所、ddrescueなるツールを知った。
ddでは不良セクタで読み取りエラーが出た所で終了してしまうけど、ddrescueならリトライするし、読み取れなかったらごにょごにょ処理してくれる。

ここでのlogはレスキューの進捗具合を記録してるので、中断しても同じログファイルを指定することで再開してくれる。便利。
-rは最大リトライ回数。デフォルト0なのでリトライしない。
実は最初はこれを指定せずに読み取ったのだが、-r 1にするだけで結果が改善した。
でも実行にかかった時間も何倍も延びた。

では、抜き取ったイメージにたいしてfsck

まずジャーナルに記録されてたことをリプレイして、その後はBtreeのノードとかをチェックしてくれた模様。最終的には「--rebuild-treeしないとどうにもならない不整合が15箇所あるよ」と言って終了した。


なので--rebuild-treeを実行。ああ、2.4.8あたりのころ、reiserfsがバグっててすごいダメージを負ったころに実行したの以来だ。reiserfsの根幹となっているB*-Treeのデータをゼロから作成する。

ではマウントしてみる

-o loopをつけてループバックマウントするのだ。
よし，復活。

不良セクタでファイルシステムが死んでしまったら、ddrescueでイメージとして抜き出して修復することが一番よい方法のようだ。イメージファイルになっているとコピーも簡単なのでfsckとかがやりたい放題。
ま、こんなことせずにすむようにRAID組むとかSMARTの不良セクタ代替の個数とかをちゃんとチェックするとかしないとねー。
ってかまだSSDじゃないの？と言われかねないな。