昨日自宅に帰って、なにげなくログインしっぱなしだった、このサーバのコンソールを見てみると、なにか見たことのないメッセージが。

journal commit I/O error

直訳するとジャーナルがコミットするときにI/Oエラーが出たよ、となるわけで(当たり前だ)、脳天気な自分ですら「こ、これはマズいのではないかｑあｗせｄｒｆｔｇｙふじこｌｐ」と思うわけだ。なのでちゃんとググってみた。が、よくわからない。ようするにファイルシステムでI/Oエラーが出たから、リードオンリーで再マウントするよん、ということらしい。

ファイルシステムで単純に論理的なエラーが発生しただけなら問題ないだろうけど、とにかくリードオンリーでマウントされても書き込みはできないし、ログも残らないわけで、それじゃ困るってことでリブートしてみることにした。しかし、オレはバカだから、何気にリブートしたあとにエラーをチェックするためにfsckをかけてしまったのだった。

昔、Sunのマシンを使っているときにカーネルパニックなどを起こしてリブートしたあとにfsckをかけるクセがあったためなんだけど、そしたらfsckしたあとにリブートしたら起動しなくなった。毎回fsckが走り、どうもこうも起動しない。起動する途中でCTRL+Cを連打してshellに落として、そこでfsckをかけてもダメ。どうやら起動している最中のディスクにfsckをかけると壊れる可能性があるらしい(ググってみたらそんなメッセージが出てたような)。

なので、CentOSのインストールディスクを別のPCで作り、そこからRescueモードで起動した。ボリューム自体はマウントできるので、そこのfstabを指定してfsckをかけてみる。

ということを朝の5時まで行ってなんとか復旧したのでした。なぜかcron.dの中にあったtripwireのcronが消えてるし…。

しかしながら、Atomマシンで2.5インチのHDDで運用しているこのサーバ。なんとなく気分的に2.5インチHDDは耐久性が少ないんじゃないか、と思ってしまっています。いや、実際にはブレードサーバなどにも採用されているし、耐衝撃性に関してはノートパソコンに積まれるくらいですので3.5インチよりも上ですから杞憂に過ぎないのでしょうが。ただ、一度こういったエラーが出てしまったディスクを長期間使い続けるのもなんなので、サーバ関連のリプレイスとバックアップ手法を考えないとマズいかな、と思っています。ML115に戻すかAtomのまま使って3.5インチに置き換えるか…。