Btrfsからxfsへ移行

■だめ、ぜったいではないが

電源周り

Btrfsは使わないほうがいいです。去年RedhatもBtrfsをobsoluteにしていたようです。トラブルに遭ってからでは遅いです。私のオススメはxfsかext4ですが、安定しているものならなんでもいいといえばいい。ファイルシステムに求められるのは最低限が安定性(堅牢性)で、それに比べたら圧縮とかdedupとかはっきりいってどうでもいいのです。

なんというか、「何もしてないのに急に壊れた」としか言いようがありません。IOエラーの類はなし。うちはECCメモリーでedacも入れてるのでUncorrectableErrorも捕捉できる。だからメモリエラーの線もなし。ある種のハイゼンバグな気がしている。


■安定性以外でもBtrfsは微妙

まずcheckとかbalanceがクッソ遅い。これはストレージの帯域の問題ではない。一晩くらいか、容量あるHDDだと何日もかかる。私は2台での運用だか、5台とかで10TB以上のものにやったら恐ろしいことになりそうだ。ちなみに同じくらいの容量でmdraidのscrubはせいぜい4時間である。読み書きのスループットが遅いと言ってる人が多いようだが、そんなでもない。まぁ、そんなに気にしてないからだが。

dedupは現状はオフライン実行だが、そんなに嬉しいものでもない。現実のデータはそんなに重複しないのだ。もう一度言います、現実のデータはそんなに重複しません。オンライン圧縮?ああ、例えば私の場合はデータに関してはmp3とかogg, pdf, xz, lz4が多いので効かないも同じ。.gitディレクトリ内のオブジェクトも圧縮されていたりする。そもそも、圧縮の効くデータはgzやらxzで圧縮してしまうのがLinuxユーザーだろうに。もっといえば、当分使わない雑多なものはtar.gz/tar.xzで固めてしまう。そうすればファイルシステム上のメタデータやinodeも節約できる。findでノイズが減る。それでいいのだ。

(なお、単に同じファイルをオフラインで検出するならfsupesのようなツールがある)

xfs/ext4はBtrfsに比べたらシンプルだと思う。自分がファイルシステムに求められるのは、シンプルさと堅牢性だったのだ。…と、やっと気づいた。シンプルの部分は直交性と言ってもいい。ファイルシステムに、ファイルシステム意外のオマケ機能を詰め込んでない、という意味だ。例えばBtrfsはファイルシステムレベルでRAIDやスナップショットをもっているので、LVMやmdraidとは相容れない。こうしてみると、そもそもなんでオレはBtrfsなんてものを選んだのだ、と過去の自分にイライラしてくる。


■移行

移行先はごく普通の構成にした。すなわち、mdraid(raid1)のPVを持つLVMで、LVはxfsでフォーマットする。raid1を構成する予定だけれども、まだ使えるドライブが一つしかない、という場合にはmissingという特別な指定が使える。すでに別のHDD(raid1)で組まれたVGがあるのでそこにPVを追加する。

$ mdadm --create --verbose --level=1 --raid-devices=2 /dev/md2 /dev/sdf1 missing

これでBtrfs(RAID1)の片側をぶっ潰して、新規raidのために使えるようになった。もう片方から新しい方へコピーすればよい。片腕失ったBtrfsは

$ mount /dev/hoge -o ro,degraded /mnt

のようにして、ro,degradedをつけることで片側運転でもマウントできる。別ドライブにバックアップはとっているのでデータが壊れていてもなんとかなるだろう。後でこれも潰してraidに--addすれば、自動でsyncが始まる。


Contents © 2018 sharow - Powered by Nikola