[[diary/Kojima]]
・Btrfsクラッシュ
Plamo用パッケージのソースコード置き場とコンパイル用の作業環境に、
ここ半年ほど使っていたBtrfsのパーティションがマウントできなくなってしまった。
# mount /dev/sdb2 /mnt2
mount: 間違ったファイルシステムタイプ、不正なオプション、
/dev/sdb2 のスーパーブロックが不正、コードページまたは
ヘルパープログラムの未指定、或いは他のエラー
In some cases useful info is found in syslog - try
dmesg | tail or so
# dmesg | tail
device fsid 3904a4c4-d58a-4185-a063-cc95cc351cb2 devid 1 transid 26007 /dev/sdb2
btrfs: unrecognized mount option 'recover'
btrfs: open_ctree failed
device fsid 3904a4c4-d58a-4185-a063-cc95cc351cb2 devid 1 transid 26007 /dev/sdb2
btrfs: disk space caching is enabled
btrfs bad tree block start 0 610606387200
btrfs bad tree block start 0 610606387200
btrfs: failed to read tree root on sdb2
btrfs: open_ctree failed
カーネルを最新の3.5.3に上げても、btrfs-progsを最新版にしてもダメみたい。
# ./Btrfs/build/btrfsck /dev/sdb2
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
read block failed check_tree_block
Couldn't read tree root
Critical roots corrupted, unable to fsck the FS
最後の望みをかけて btrfs-restore でファイルシステムの中身を取り出そうとしてもダメだった。
# ./Btrfs/build/btrfs-restore /dev/sdb2 /nfs/Btrfs-restore/
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
Check tree block failed, want=610606387200, have=0
read block failed check_tree_block
Couldn't read tree root
btrfs-restore: extent_io.c:602: free_extent_buffer: Assertion `!(eb->refs < 0)' failed.
中止
ソースコードの置き場用だったので、サブボリュームは作ってないし、スナップショットも取ってない、ごくシンプルな構造だと思うのだけど、B tree構造の根本の方で壊れたのか、ファイルシステムは全滅っぽい。
そう言えば、ここ数週間ほどBtrfsな上で作業をしていると、ファイルシステムの反応が鈍くなることがあって、その時は特にチェックしなかったのだけど、そのあたりから壊れかけていたのかも知れん。
まぁ、このファイルシステムに置いていた、パッケージ作成用のソースコードやビルドスクリプト、パッチファイルのうち、手元で作っているビルドスクリプトとパッチファイルはバイナリパッケージに同梱していて /usr/share/doc/以下にインストールされているし、
ソースコードもビルドスクリプトに記載のURLからダウンロードすれば復元可能なはずなので、
「ここ以外に存在しないファイル」は（多分）無かったように思うのだけど、
500GBくらいの規模になっていたから、かなり痛いのは事実。。。
半分はテストのつもりで、NFS経由で32ビット機のコンパイル作業にも使っていたので、
ファイルシステムへの負荷はかなり高かったのかも知れないけど、
特に目立った予兆もなしに、
マウントや復旧できないレベルにまで壊れてしまうというのは、
「実用的に使うには難あり」という評価になりそうだな。
そー言えば、ReiserFSのころにも、同じように復旧できないレベルのクラッシュに
見舞われたことがあって、しばらくReiserFSを敬遠しているうちに、
例の事件で開発が止まってしまった、なんてこともあったなぁ。
今回、復旧する方法が無いか、とGoogleあたりを調べてみたのだけど、
Btrfsの公式サイトの情報がwikiレベルだし、
そこにある情報はすでにgitの中身と異なっているし、
btrfs-mlに報告されている似たようなトラブルに対して、
「ツールやカーネルを最新版にする」以外の解決方法が示されていないのを見るにつけ、
かってのReiserFSのころの悪夢が蘇えってきてしまった :-P
# ReiserFSの開発元のnamesysのサイトには、reiserFSの仕様や機能ではなく「名前空間(namespace)」に関する哲学（衒学）的な記述ばっかり書いてあったっけ。。
多分Btrfsも、開発が一段落して、開発者達が機能や仕様、使い方といった、
面倒で面白くないドキュメントを書き出すようにならないと、
一般人からも安心して利用できるようにはならないのだろうな。
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
