btrfs replace /dev/sdd2 /dev/sdb1 /homeしたら、システムが停止し、I/Oも停止。やむなく再起動したところ、案の定マウントできない。ちなみに、10.3%で、writeerrが1776あった。

理屈から言えばbtrfsはこのような場合でもデータを失ってはいないはずだ。なぜなら、btrfs replaceは新規デバイスにデータをコピーし、成功した場合にリファレンスを付け替える構造だからだ。

だが、現実はこのbtrfsファイルシステムにアクセスできない。1TB近いデータの損失は、バックアップをとってから結構重要なデータも増えており、致命的な状態だ。RAIDでカバーすることを基本としているだけに、ファイルシステム破損のダメージは大きい。

とりあえず、btrfsckしてみる。1200万ものエラーが発見された。だが、これによってマウントはマウント時にかなり待たされるものの、可能になった。ただし、失敗することもある。

それで再起動してみたが、やはりマウントできずコンソールに落ちる。btrfs device replace status /homeした上で、btrfs scrub start /homeしてみる。すぐにプロンプトは戻るが、btrfs scrub status /homeすると0secでabortされていることがわかる。明らかに異常な状態だ。

ファイルシステムをマウントすることができ（いつの間にかマウントを失っていることもあるが）、またファイルシステムにアクセスできるのだから、今のうちにデータをバックアップしておくべきだ。そう思い立ち、今までWindowsが入っていた（どのみちリカバリーのために消さなくてはいけない）ディスクをnukeし、XFSで再フォーマットした上でデータをコピーする。

構造として、/homeと/home/aki/shareにサブボリュームがマウントされているので、なかなかややこしい状態になっている。多分、btrfsのサブボリュームは、単にマスターボリューム以下にあるあるディレクトリをファイルシステムルートにみせかけているだけだと思うので、純粋にbtrfsのマスターボリュームをコピーすればいいのではないか、という気がするのだが、それでうまくいかなくかった時が怖いので、素直にサブボリュームをマウントした上でそれをコピーする。

最初のほうはかなりひっかかっていたが、やがてスムーズに動くようになった。もしかしてアクセスしながら自動的にbtrfsが修復していったということだろうか？（私のbtrfsは、2レッグミラーになっている）

そして完了後に別のサブボリュームをマウント、すぐに反応してくれる。異常な印象は受けない。ためしにscrubしてみると、なんと正常にスタートした！/homeも一応バックアップを取った上で、再起動してみると、正常にブートした。しかもそれだけではない。かねてから正常に動いていなかった「display1で正常にポインターカーソルが表示されない」「SEが出ない」も解消されている！一体なぜだろう。

とりあえずscrubした上で途中になっていたファイルシステムのメンテナンスを行い、そしてバックアップからの差分が膨らまないうちにと、今度はbtrfs device add /dev/sdb1; btrfs device del /dev/sdd2作戦。addは一瞬で終わる。一方、delは時間がかかる。これは正しい。addは本来ファイルシステムを作るだけだし、btrfsはマークをつけておくだけだったように思う。一方、delはデータを他のデバイスにコピーしてからリファレンスを消すので、そのデバイスのデータ分時間がかかる。まだ途中だが、今のところ支障はない。

ちなみに、そもそもなんでデバイス移行しようとしているかというと、LVM用に確保してあった領域を削除し、全域をbtrfsに割り当てるためである。

btrfsの不完全さのせいで生じたトラブルだが、btrfsの冗長性、可用性に救われた形になる。どういう反応をすれば良いのやら…