RSS2.0
以前トラブってfsckがエラー吐きまくったサーバ
ですが、600GBある/homeのfsckがなかなか終わらなかったため、システム復旧に時間がかかりました。
その反省を踏まえ、/homeの中でも容量食うくせに使用頻度の少ないディレクトリを別パーティションに分離、システム復旧時にはこれらのfsckは後回しにできるようにする変更を。
大きなデータが退去した/homeのパーティションは、そのままでは空き領域が大きすぎるので縮めることに。LinuxのLVM(Logical Volume Manager)で管理されたボリュームにあるので、GNU Parted とかQT Parted とかは使えず、コマンドラインからの操作となります。とはいえ、この手の情報は検索すれば大量にヒットしまして、シングルモードに移ってから、# umount /home # e2fsck -f /home # resize2fs -p /dev/VolumeGruop1/home 500G # lvresize -L 500G /dev/VolumeGruop1/home # mount /homeなどとすればOK。個人的にはresize2fsとlvresizeの500GBは同じ定義(1KBは1024Bか1000Bかというお話)かと心配でしたが、この二つのコマンドは同じ定義のようです。
さてこのサーバの立ち上げ時、私は/homeほか大容量のパーティションのファイルシステムをext3, xfs, reiserFS(そう言えば、Reiserさん有罪になっちゃった みたいですね)のどれにしようか迷いました。最初に候補落ちしたのはreiserFSで、SUSE Linux が将来性が不透明という理由で標準ファイルシステムをreiserFSからext3に変更したのが気になったから。
- 縮小ができないこと
- 大容量のパーティションで修理ができなくなる可能性があること
もうひとつは意外と知られてないかもしれません。xfsでfsckに相当するxfsrepairコマンドは1GB当たり1～2MBのメモリを使用します。ファイルシステムのサイズが小さいうちはこれは問題にはなりませんが、2TBを超えるようになると必要メモリが4GB以上になります。
これ、メモリアドレス空間が4GBしかないi386では大問題です。メモリをどんなに付けようが、スワップファイルをどんなに割り当てようが、CPUの制限でOSは4GB以上の記憶容量は提供できません。つまりxfsファイルシステムに損傷が起きても、メモリ不足で修復できなくなってしまうのです。修復できなければマウントもできないので、生き残ったデータだけ吸い出すということもできません。
x86_64では広大なアドレス空間がありますので、時間がかかって良いならメモリが無くてもスワップファイルを追加、ごり押しで修復できる道が残されています。ならば修復のときだけx86_64のマシンにつないでやれば良いじゃないか、と私も考えたのですが、どうもxfsはi386とx86_64では互換性が無いらしく、この方法も使えず。
2年以上前の判断ですので今は改善されているといいのですが、もともとxfsは広大なアドレス空間を持つSilicon Graphicsのマシン用に開発されたもの、今更滅び行くi386に対応するよりx86_64に換えてくれということになってるのではないかと。
i386のLinuxで2TBを超えるxfsなんてことやらなければこんな問題気にしなくてすみますので、そのように運用すればいい話です。私の場合はx86_64のマシンが手に入らず、大容量でのパフォーマンスが売りのxfsで小容量の運用してもなぁと思い、ext3にしたわけです。
Y:
Comments