Btrfs ファイルシステム修復

提供:TuntunkunMediaWiki

移動: 案内, 検索

目次

Btrfs ファイルシステムの修復

背景

私個人が実験目的で利用している内向きサーバーでは複数のディスクから構成されたディスクプールを利用し、メタデータ・データ共に RAID10 構成をとっている。このシステム上で動画のエンコードなどのタスクを複数プロセス走らせたり、頻繁なランダムアクセスをするソフトを走らせたりして btrfs ファイルシステムの対障害性について調べてきた。このような高負荷状態で雷等による瞬断が発生するとファイルシステムはいとも簡単に壊れてしまった。そのため、UPS を購入したのだがそれでもなお kernel クラッシュが起こるった場合には高確率でファイルシステムが壊れてしまう。ファイルシステムの修復機能がなくとも btrfs ファイルシステムのもつスナップショット機能は優秀で、すべての btrfs ファイルシステムにアクセスするプロセスを止めた状態でスナップショットを定期的にとっておけば仮にファイルシステムが壊れてしまってもスナップショットは無事なことが多い。そのため、こまめにスナップショットを取ることは障害復旧の観点からとても便利である。しかし、この方法で運用していくと大抵の場合は症状が悪化していった。kernel 3.0 になって以降初めて大きなクラッシュを起こした私は、btrfs-progs の最新版を用いての修復を試みたのでここにその復旧に至るまでの道筋を記そうと思う。

最新版 btrfs-progs のビルド

最新の btrfs-progs をビルドする前に、ビルドに必要なコンパイラやライブラリ、カーネルヘッダーなどの必要なパッケージをインストールする必要がある。しかし、依存するパッケージを正確には把握していないので開発環境一式を次のようにインストールすると確実だろう。

# yum -y groupinstall "Development Tools"

次に、btrfs-progs の他の依存関係を解決する。必要なパッケージは、libuuid-devel, libattr-devel, zlib-devel で次のようにインストールする。

# yum -y install libuuid-devel libattr-devel zlib-devel

これで、btrfs-progs をビルドするための準備は整いました。次に、kernel.org の git リポジトリから btrfs-progs のソースコードを取得します。

$ mkdir ~/src
$ cd ~/src
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git

ソースコードの取得ができたらあとは、ビルドしてインストールするだけです。btrfs-progs では現在 Makefile のみで configure スクリプトがないため比較的簡単にコンパイルすることができます。

$ cd ~/src/btrfs-progs
$ make
$ sudo make install

これでインストールは完了です。

ファイルシステムの修復(ケース1)

実際に壊れたファイルシステムを修復するには btrfs コマンドのサブコマンドである scrub を利用する。このコマンドはファイルシステムがマウントされた状態でも動作するが、このコマンド自体がとても高い負荷がかかるため他のプログラムは停止しておいたほうがいいだろう。この処理はサブボリューム単位ではなく、ファイルシステム単位で行われる。どのファイルシステムを修復するかの指定方法はデバイス名(ディスクプールの場合はメンバーのどれか一つ)、マウントポイント(サブボリュームのものでも可)などいろんな方法があるが、すでにマウントされている前提なら後者のマウントポイントが楽だろう。ここでは btrfs のファイルシステムが /home にマウントされているとする。

$ sudo /usr/local/bin/btrfs scrub start -B /home
scrub done for fbbd7922-e2a7-41cb-9fad-adb4fd9db7eb
       scrub started at Fri Feb  3 12:04:41 2012 and finished after 4000 seconds
       total bytes scrubbed: 648.69GB with 221 errors
       error details: read=111 verify=44 csum=66
       corrected errors: 111, uncorrectable errors: 0, unverified errors: 0

たったこれだけで、ファイルシステムの修復ができる。マルチスレッドで動作するようで、すべての CPU が 99% に張り付いてしまった。修復結果が返されるまでに長い時間がかかるが、気長に待つしかない。キャンセルしたい場合は、次のようにすれば止めることができる。

$ sudo /usr/local/bin/btrfs scrub cancel /home

今回は、111 ものエラーがすべて正しく修正された。やっと RAID10 構成にしていた恩恵を実感することができた。現在はまだ、未使用領域のチェックが実装されていないようだが、scrub 機能のおかげで十分に実用的なファイルシステムになったと言えるだろう。

ファイルシステムの修復(ケース2)

復旧ツールの登場のおかげで問題が起こっても焦らず対処することができるようになったが、HDD の寿命によっておこる物理的障害によってファイルシステムがマウントできない状態になってしまった。S.M.A.R.T を見ると Reallocated Sector Count が 1 になっていることがわかった。このまま、永久にデータを失ってしまうのは嫌だ。こういった時のためにメタデータ・データ共に RAID10 にしてきたのだからなんとしても復旧したい。とりあえず問題の HDD を抜いて、degraded モードでマウントをしてみた。

$ sudo mount -t btrfs -o degraded /dev/sdb /home

マウントはすんなり成功した。しかし、このままでは HDD の RAID がバランスが崩れていてここで問題を起こすと復旧が困難になる。HDD を追加する余裕はなかったので、とりあえず今あるディスクのみで RAID を再構成することにする。

$ sudo /usr/local/bin/btrfs device delete missing /home

このコマンドを実行することで、取り外した壊れた HDD が担っていたデータを他のディスクに担わせることができる。このコマンドが正常に完了すれば degraded モードではない通常の方法でマウントが可能になるはずだ。

$ sudo mount -t btrfs -o remount /dev/sdb /home

通常通りマウントができれば正常に復旧が完了しているはずだが、ちゃんとファイルシステムが復元されているか多少の心配が残ったので scrub もかけることにした。

$ sudo /usr/local/bin/btrfs scrub start /home

scrub 処理はバックグラウンドで動作するため進捗状況を確認するには、別にコマンドを実行する必要がある。

$ watch /usr/local/bin/btrfs scrub status -d /home

このコマンドを実行することで scrub 処理がどこまで進んだか確認できる。しかし、scrub した容量と scrub 処理が始まってからの時間しか教えてくれない。そのため、btrfs コマンドでそれぞれのデバイスがどれだけの容量を記録しているのかを確認しておかないと進捗状況を知ることはできない。

$ sudo /usr/local/bin/btrfs filesystem show /home

ここでデバイスごとに表示される使用料が、scrub しなければならない容量なので status で表示される scrub された容量を見ることでどの程度 scrub 処理が進んだかを理解することができる。

個人用ツール
名前空間
変種
操作
案内
ツールボックス