以前トラブって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を落とした理由は二つあります。

1. 縮小ができないこと
2. 大容量のパーティションで修理ができなくなる可能性があること

一番目は今回の変更でもやりましたが、縮小ができないということはせっかくのLVMによるディスク管理の柔軟性に制限をかけてしまうことになります。

もうひとつは意外と知られてないかもしれません。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にしたわけです。

今年もグロい画像を掲載する日がやって来ました。健康診断です。胃カメラです。一年前の記憶 など頭に残っておらず､今年も飲み込む要領つかめず､3回ほどえづく。そういえば去年もこんな風に軽く意識が遠のいたことを思い出しながら､そんな状態で画面に映っている内容の説明されたって､まともに判断できやしないｗ

胃カメラの結果はいたって良好で､丸で囲んだ部分に潰瘍の後があるけど問題無しとのこと。しかしまた便検査で潜血が出てしまった。私は強度の便秘の上に便が固いので排便するとかなりの確率で出口を傷つけ出血するわけで、そのせいだと思うのだけど・・・また大腸内視鏡 か・・・・？

ひょんなことから12の82乗なんていうとんでもない計算をすることになったのですが、結果は10の82乗よりも大きいわけで、83桁以上なことは確実。64ビット浮動小数点 を越える計算、さてどうしたものかと思ったらこの手の計算は複数の言語でサポートされているらしい。

PerlではMath::BigIntクラスがそれにあたり、Perl 5.8からは標準で含まれる。それ以前のPerlでもCPANでインストール可能で

cpan -i Math::BigInt

でOK。で、以下のスクリプトを組んでめでたく89桁の結果を得ました。

bash-2.04$ cat test.pl
#!/usr/bin/perl

use Math::BigInt;

$x = Math::BigInt->new("12");
$x = $x ** 82;
print $x->bsstr()."¥n";

bash-2.04$ ./test.pl
31107289852948419532830210325169922767038593747425104848349825951609481990716300348882944e+0

玄箱 で1秒足らずで出力されましたが、もっと桁数の大きい計算を繰り返すには遅すぎるのでGMP とそれに対応するPerlライブラリMath::BigInt::GMPを使用すれば速くなるとのこと。小数を含む計算にはMath::BigFloat。

こういうこと経験すると、計算機って便利だなと思う次第。

[参考]

• Perl 5.8 Documentation
• まめめも
• GMP

いつの間にやらKNOPPIX のバージョン5.3.1がリリースされていた。カーネルバージョンが2.6.24 。やっとIntel G33チップセットのVostro200 で動いてくれました。

現時点DVD版しかリリースされておらず、ダウンロードに3時間かかる。MSDN の配布メディアもCD-ROMが廃止されDVD-ROMのみになりましたし、最近はDVDドライブを搭載していないマシンなんて無いという判断なのでしょう。

で、ついにGPUを活用するデスクトップになっておりました。とりあえず気づいた効果は、

• ウィンドウを移動させると引き伸ばされたように変形する
• ウィンドウやメニューが消えるときに波打ちながらフェードアウト(半透明を経て消える)
• 微妙にウィンドウに影がついている?

でしょうか。ちょっと効果がくどい気がする。Windows VistaのAeroの方がなんとなく品があるような。慣れかもしれませんが。こういうの入れだすとCD-ROMに収めるのは難しいかもな～

あとブラウザがFirefoxではなくなっていました。私はKNOPPIXでブラウザは滅多に使いませんが、Firefoxに問題でもあったのだろうか?

[2008/5/19 追記] KNOPPIXにはFirefoxが入っていたと勘違いしていた。

してしまった。今週頭から体調悪いとは言っていたけど、今日出社するなり具合が悪くなり、そのまま救急車・・・。精密検査が必要でGW前の復帰は無理だとか。あぁ、もうちょっと仕事手伝ってあげればよかったと思いつつ、来週から降りかかる仕事はわが身に(゜д゜;)