前にも少し書きましたが、FreeBSDを i386 版から amd64　に切り替えたので、PHPの整数型変数の取扱いが少々変わっています。てことでちょっと実験してみました。

<?php
$a = 1;
$b = 1;
while($a>0) {
    $a = (integer)($a * 2);
    echo "2^$b = " , $a , "\n";
    $b++;
}
?>

i386の場合

2^1 = 2
2^2 = 4
2^3 = 8
(略)
2^30 = 1073741824
2^31 = -2147483648

amd64の場合

2^1 = 2
2^2 = 4
2^3 = 8
(略)
2^30 = 1073741824
2^31 = 2147483648
(略)
2^62 = 4611686018427387904
2^63 = -9223372036854775808

ビデオキャプチャの録画データを扱っていると、ファイルサイズが 2^31-1 バイトを超えることも珍しくありません。裏ワザを使わずとも受け取った値をそのまま使えるってのはなかなか便利です。「整数型なんて32ビット長あれば十分」と思っていましたが、実際には十分じゃないので長くても遅くならないのであればこっちの方が良いですな。

参考までに、64ビット整数型はどれくらいのファイルサイズまで扱えるのか数えてみました。

E   P   T   G   M   K
4,611,686,018,427,387,904

えーと、きろ・めが・ぎが・てら・ぺた・えくさ、、ですか? 我が家のHDDは「次は夢のいちてら!!」というレベルなので当面は大丈夫そうですね。

そして、上の数字を日本円に直すと4百京円。京ってどれくらいの金額なんだろう(笑)?　百万円ぐらいの数字は読めるのですが、それより上の位にカンマが4つもある世界なんてよくわかんないです。

uptime が 2日を超えました。以前は24時間持たなかったような気がするのと、本運用しながら試験してるので期間が長くなるとHDDの入れ替えでは元に戻らないということで、UFSのまま残していたHDDを本来の用途どおりミラーリングに使うことにしました。

toriyu# zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          ad0       ONLINE       0     0     0
errors: No known data errors

toriyu# zpool attach tank ad0 ad1

toriyu# zpool status
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress, 29.01% done, 0h39m to go
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            ad0     ONLINE       0     0     0
            ad1     ONLINE       0     0     0
errors: No known data errors

よしよし、ちゃんとミラーが構築されていってますね。attach時点のプール使用量は50GBぐらいなのですが、約40分でミラー構築が完了しました。

toriyu# zpool status
  pool: tank
 state: ONLINE
 scrub: resilver completed with 0 errors on Wed Jan 14 11:48:43 2009
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            ad0     ONLINE       0     0     0
            ad1     ONLINE       0     0     0
errors: No known data errors

なお、ミラー前後及び途中で昨日の簡単ベンチマークはどういう感じになるのかも計ってみました。

ファイルシステム	WRITE		READ		COPY
	(秒)	(MB/秒)	(秒)	(MB/秒)	(秒)
ZFS 1ドライブ	15.8	66	14.5	73	30.2
ZFS ミラー構築中	15.2	69	18.6	56	40.4
ZFS ミラー完了	13.4	78	16.5	63	30.7

複数回測定するとバラツキがあるので値の大小にはあまり意味がないのですが、とりあえず次のことは言えます。

• ミラー後の write　のパフォーマンス低下はほとんど無い
• 巨大な単一ファイルにおいてはミラーによる read パフォーマンス向上も無い
• ミラー構築中でもパフォーマンス低下はそれほど大きくない

つまり良くも悪くも1ドライブ構成と同じと(^_^)。あとはUFSとおんなじように安定して動くかどうかですね。

# snapshot と zfs send を使えば極めて短時間でバックアップが
# 取れるので、UFSより遅くてもちゃんと動けばZFSの方が良いデス。

□ 関連記事

• 2009/01/12 ZFSに再挑戦
  • 2009/01/14 ZFS ミラー ≪

iSCSIブートがうまくいかないよ～な毎日なのですが、あきらめてNICのiSCSIブート機能を解除しようとDOSのユーティリティを立ち上げた時に気付きました。

-WOLENABLE または -WOLE 選択されたアダプタで Wake On LAN 機能を有効にします。

あり? そんなオプションがあったのね。実験してみると、FreeBSDから wol コマンドでS5から起動できました。

おぉー、これはイイですね。実験用に使ったPCはオンボードで Atheros L1 Gigabit Ethernet controler が入ってるのですが、これはWOLに対応しているものの、Windowsでドライバを入れてWindowsのドライバ設定で「電源OFFからのwake up を有効にする」とかしないといけなかったのです。だからFreeBSDを入れたらWOLは使えないと。だけど intel のサーバアダプタならそんなの関係なしに起動できるのですな。これは素晴らしいです。

APM末期の頃のWOLは問答無用でマジックパケットを送れば起動していたのですが、最近はソフトウェアで設定可能になっていて困ったことにWOL無効がデフォルトなのでFreeBSDで使えないことが多かったのです。

サーバーのバックアップはFreeBSD機をWOLで起動して ssh で送っているのですが、送り先のPCが古くてギガビットイーサのssh+zfs compressなんて荷が重すぎて困っていたのです。シングルコアなのにロードアベレージが1を大きく超えるし(笑)。このNICがWOL起動できるのであればPCはなんでも良いのでリプレース時には困らなくて済みそうです。価格には見合いませんが、良い使い道が見つかりました(^_^)。

□ 関連記事

• 2009/01/11 インテルサーバーアダプタ
  • 2009/01/14 怪我の功名 ≪

使えないことはわかっているのですが、せっかく今はいろいろ評価できる状況にあるので64ビット版を試しに使ってみました。

結果はご覧の通り(笑)。ビデオキャプチャカードのインストールCDメニューからデバイスドライバのインストールを選ぶとこうなります。デバイスマネージャーからCDのディレクトリを指定して入れようとしても入りません。なんかダメっぽいですな。タイマー録画プログラムの方はちゃんとインストールしてご丁寧にUACも切ってくれるのですが、ドライバが無いので録画できません。

Vista入れるかどうかはまだ決まっていないのですが、入れるにしても64bit版はダメみたいです。