XenのDomainUのファイルシステム障害をDomain0から直す
昨日XenのDomainUのひとつがいつの間にかRead-onlyになっていた。
とりあえずログを見ても原因がわからない。何らかのI/O負荷に伴うものだろうか。
muninのグラフを見ると障害の直前までに徐々に負荷が高まっている様子が確認できたので、なんとなく状況は把握。
この負荷が高まった原因については分かっているけど、すぐに対応できるものではないのでこちらはタスクに放り込んでスルーしておく。
止まっても緊急性のないサーバなのでのんびりと復旧を開始した。
ひとまず再起動
しょっぱなから適当に最強の回復魔法を試してみたのだが撃沈。
どうもブートの途中でひっかかってしまって起動しなくなった。
起動時にfsckが走ることを期待したのだが、そこまでも行かないっぽい。
しかしながらXenのconsoleから確認するとディスクをマウントするところで止まっているっぽいので、やはりまずはfsckをかけたいところだ。
Domain0からディスクイメージの中身をfsck
そこでDomain0からイメージファイルの中身を触って修復することにした。
まずディスクイメージをloopデバイスに割り当てる
これにはlosetupを使う。
# losetup /dev/loop0 /var/lib/xen/images/hoge.imgまだこの状態ではfsckかけてもext2じゃないよとか言われて動かないので更にパーティションごとにアクセスできるようにする。
# kpartx -a /dev/loop0これで/dev/mapper/以下にloop0p1からloop0p8までパーティションに応じたデバイスができるので、これらをfsckすることができるようになった。
# e2fsck -c -f /dev/mapper/loop0p1p4が欠番でp3はswapなのでスルーしてp1,p2,p5,p6,p7,p8を順にfsck。
p7とp8でいくつか不良ブロックが見つかったのでyを何回か押して修復完了。
最後に後始末しておしまい。
# kpartx -d /dev/loop0
# losetup -d /dev/loop0これで再度起動すると無事起動して動き出した。
素晴らしい。
