Kinesis Contoured Keyboardの余白に置くにふさわしいトラックパッドを求めていた私だが、Cirqueのサイトをたまに眺めては、発展の止まったデスクトップ用デバイスに嘆息していた。

一方、職場ではトラックボールをこよなく愛しつつも、家のリビングルームには居場所がない。また、究極と言われるSlimBlade Trackballも、それ自体が種の進化の終焉を示しているようでもあった。

そこに彗星のごとく現れたMagic Trackpad！！さっそく入手してKinesisの腹に載っけてみたが、これはいまいちだった。というか、底面によって検知される押し込みによるクリックが便利なのだ。押し込みを効果的に使うにあたってはコツがあって、それは親指のホームポジションを意識すること。Magic Trackpadは広いのでついつい上の方で操作してしまいがちなのだが、親指ともう一本の指を接地した状態でドラッグ操作を行うには、親指がパッドの下部約2cm以内になければならない。もちろんダブルタップ＆ホールドによるドラッグ操作もあるが、ドラッグのために二回タップするのはマウスやトラックボールに慣れた身にはまったく直感的ではない。従って、パッドの下部には見えない物理ボタンがあると思って使うのが良い。

ちょっと古いMacBookシリーズを使っているとトラックパッドなんかメインで使う気がしないものだが、こいつはかなり革新的。十分な広さと慣性スクロールのおかげでナビゲートが快適すぎる。

ところが、マウスから乗り換えて愕然とするのが、ホイールクリックができないという事実。今どきブラウザを使う上でタブを活用するのは当然で、ニュースヘッドラインからポチポチと「新しいタブで開く」ことから一日が始まる人も多いだろう。しかしトラックパッドではそれができないのである。Commandキーを押しながらタップだとか、二本指タップでコンテクストメニューから選ぶなんてのは不便すぎる。

しかし、もちろん解はある。Macユーザなら、何はともあれBetterTouchToolを入れるべきである。これを使って、たとえば三本指タップをホイールクリック（”Middle Click”）に設定すればいい。あるいは、中指を接地した状態で人差し指をタップする操作（TipTapと名付けられている）などに割り当ててもいいだろう。ほかにも、四本指でアプリケーション切替メニューを出すとか、四本指スワイプでSpacesを切り替えるとか、もろもろ設定し放題。

Magic Trackpadで残念なのは、せっかくBluetoothでポータブルなのに、同時にペアリングできるのが一台のみという制約。ペアリングし直しにさして時間がかかるわけではないけれど、何かエレガントな切り替え方を提供してほしかった。（ファームウェア更新等で対応されるかもしれないが）

ともあれ、直接触れるデバイスにこそお金を使おうという人なら複数台買うくらいの価値はあるように思う。ポインティングデバイスはここ数年おもしろい動きがなかった。マウスには飽きた。トラックボールはでかいし掃除が面倒だ。となれば乗るしかない、このブレイクスルーに！

WebFontはもっと流行るべきなので、俺もデコもじを使ってみる。カテゴリによって書体を分けたい気がするから、テンプレートをいじって記事全体のdivのclassにカテゴリのslugを入れるようにしてみようかな。

いろいろと試行錯誤したが、freebsd-fs@あたりの議論を参考にすると、vm.kmem_size_maxはFreeBSD起動時の”avail memory”の値の2倍まで増やせるらしい。このマシンは

real memory  = 8589934592 (8192 MB)
avail memory = 8256999424 (7874 MB)

なので、

vm.kmem_size="1536M"
vm.kmem_size_max="15360M"
vfs.zfs.arc_max="3584M"

としてみた。あと、どうも入ったばかりの-DZIO_USE_UMAが不安定要因のようなので、sys/modules/zfs/Makefileでコメントアウトしてリビルド。sysctl(8), vmstat(8), top(1)などの出力をウォッチしながら、3日目に入ったところ。さて、落ちずにどこまで行くかな。

たとえばOSや言語などの開発に関わったことのある人間ならわかると思うが、ある機能を潜在的な意味で「やれば実現できる」ことと、すぐに使える状態で「備えている」ことの間には大きな隔たりがある。

さまざまな制約や事情が許さない場合もあるが、原則的に、三度、四度と使い回したことのあるパラグラフや、短くても一見して意味の取りづらいフレーズは、抽象化した上でよい名前を付けるべきである。ピコピコポンを第一話から見ていた者ならすぐに分かることだが、名前を知り、あるいは付けることで、初めて見えてくる新たな地平というものがある。

物事を学習する過程というのは、新しい概念を受け入れ、さらに上位の概念を理解するための基本語彙とすることの繰り返しである。小手先の機転に固執したり、迂遠な表現をイディオムとしてありがたがったり、毎度毎度その場の曲芸を演じるばかりでは進歩がない。

プログラミングにおけるイディオムとかtipsとかHOW-TOとかを集めるひまがあったら、その中でめぼしいものをさっさと言語化（機能化）して一言で言えるようにすりゃいいとむかーしから思っていて、実際にそれに沿って行動してきたつもりだが、そんなことをわざわざ言う機会はあまりないなと執筆をしながら思ったのでここに書き残しておく次第。

ML115 G5のファン換装の後、CPUファンを超静音のものに替えたのだけど、残念ながら風量が足りないようで、CPUをぶん回すと温度がうなぎ登り。ついに、ゴールデンウィーク中の夏のような暖かさの前にハングしてしまった。

そこでCPUファンを山洋電機のPWM対応静音ファンに変え、3.5インチベイ群の前に薄型静音8cmファンを据えて満載のHDDの熱を後方に送りつつ、その風の出口、チップセット前にアーム付きファンを設置して廃熱を図った。空きPCIスロットのダミーベゼルは外してあり、手を当てるとほのかな温風が出ている。もうちょっと効率が上がるように、内部と、あと部屋の隅に熱がこもらないように外にもエアーダクトが必要かも。

なんかもうファンが5個くらいあるんだけど、それでも初期状態よりは静かだ。たまにPWMで回転数が上がるんだけど、フイーン、ですぐに戻る。さて、これで夏を越せるかな？

今もFreeBSD 8/amd64でZFSを使うときのパラメータについては試行錯誤中だが、最近、NFSサーバとしてVirtualBoxゲスト達からマウントされるようになると、ちょいちょい2,3日に一度くらいkmem_mapが溢れて落ちるようになってしまった。
ということで現在はvm.kmem_size_maxを4GBに増やして様子を見ている。

ハードディスクを大容量のものに交換して密度が上がったせいか、ML115 G5のケース内温度が上昇してファンがうるさくなった。この筐体にはもともと1Uサーバ並のうるさいファンが付いており、起動時以外は我慢の範囲に収まっていたのだが、負荷が上昇するたびにクオーンと鳴かれてはたまらない。
そこで背面の轟音ファンをOwltechの静音ファンOWL-FY0925Lに替え、フロントに吸気ファンとして同OWL-FY0825Lを付けたところ、だいぶ静かになった。フロントには合うねじ穴がないので結束バンドで固定した。

とりあえず、妻は興味がないせいかファンを替える前の音も気にならなかったというが、俺は次はCPUファンと電源ファンの音が気になってきた…が、また我慢できなくなったらでいいや。

さっそくport multiplier箱でホットスワップを試してみたら、抜くときは問題なく一台だけdetachされるのだが、挿したときは同じportにつながっているディスクがすべてdetachされてしまい、改めて全ディスクがattachされた。port multiplierの仕様なのか、筐体の仕様なのか、それともドライバの仕様なのかはわからないが、これではちょっと厳しい。unmountが必要では、無停止で交換・増設というわけには行かなさそうだ。（まあ、すべてミラーならdetachすればいいけど手順としてそれはどうよ）

FreeBSDにおけるZFSのチューニング資料として、まず見るべきはZFS Tuning Guideだと思うが、これによれば、ことFreeBSD 8/amd64に関しては特に設定不要であるように読める。
しかし、ZFSは高負荷になるとkmemを激しい勢いで消費するので、特に多機能サーバとして使っている場合は、適切な設定でkmemの消費を抑える必要がある。通常の利用では問題なくとも、bonnie++などでストレスをかけると簡単に落ちてしまう。
8GBのメモリを積んだ手元のサーバは、以下のような設定（/boot/loader.conf）にしたところ、相当の負荷にも耐えられるようになった。

vm.kmem_size="1536M"
vm.kmem_size_max="1536M"
vfs.zfs.arc_min="128M"
vfs.zfs.arc_max="512M"

2GBとか4GBでの例はちらほら見かけるが、8GBなら値を比例で増やせばいいというものではないので、無駄をなくすべくこれでも調整には試行錯誤した。今時8GBくらい普通だと思うので、ほかにも事例があれば知りたい。

内部処理を4KB/sectorで行うというWD Caviar Green (Advanced Format)シリーズのハードディスク、WD15EARSを調達したので性能を見てみる。昨日の記事の通り、OSはFreeBSD 8/amd64、接続インターフェースはeSATAである。
まず、単体のraw書き込み性能を見てみる。

% sudo dd if=/dev/zero of=/dev/ada0 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 104.850489 secs (100006782 bytes/sec)

つまり100MB/s弱だ。eSATAインターフェースカードで律速していないかは、後日内蔵SATAと比較するとしよう。
それでは、一台まるごとZFSにしてbonnie++で測ってみる。

% sudo zpool create test ada0
% sudo bonnie++ -d /test -n 64:102400:128:8 -u root
Writing a byte at a time...done
[...]
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
daemon.musha.or 16G   138  99 58072  13 28952   6   420  99 82789   9  86.6   2
Latency               197ms    6496ms    8717ms   46942us    1645ms    2071ms
Version  1.96       ------Sequential Create------ --------Random Create--------
daemon.musha.org    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    64:102400:128/8   139   3    82   1 17323  77    92   2    52   0    48   0
Latency             41400ms    5563ms   81225us   34264ms    6496ms    9847ms
1.96,1.96,daemon.musha.org,1,1271143734,16G,,138,99,58072,13,28952,6,420,99,82789,9,86.6,2,64,102400,128,,8,139,3,82,1,17323,77,92,2,52,0,48,0,197ms,6496ms,8717ms,46942us,1645ms,2071ms,41400ms,5563ms,81225us,34264ms,6496ms,9847ms
% sudo zpool destroy test

…うーん、シーケンシャル書き込みが58MB/sとはちょっとさびしい。
ところで、このディスクはどのように諸元情報を返しているのだろうか。

% sudo camcontrol identify ada0 | grep 'sector size'
sector size           logical 512, physical 512, offset 0

古いOSの互換性のためなのか、physical sector sizeも512Bと返しているようだ。ジャンパー設定を調べたが、残念ながらこれを変えることはできない模様。
それでは、GEOMを使って4KB/sectorでアクセスするようにしてみよう。

% sudo gnop create -S 4096 ada0
% sudo zpool create test ada0.nop
% sudo bonnie++ -d /test -n 64:102400:128:8 -u root
Writing a byte at a time...done
[...]
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
daemon.musha.or 16G   129  99 68255  15 38455   8   434  99 88872   9 100.1   2
Latency             64647us    5964ms    6305ms   37390us    1907ms    1397ms
Version  1.96       ------Sequential Create------ --------Random Create--------
daemon.musha.org    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    64:102400:128/8   776  19   115   1 17922  82   790  20   110   1 21075  96
Latency              7490ms    1116ms     108ms    7415ms    1015ms   22992us
1.96,1.96,daemon.musha.org,1,1271239571,16G,,129,99,68255,15,38455,8,434,99,88872,9,100.1,2,64,102400,128,,8,776,19,115,1,17922,82,790,20,110,1,21075,96,64647us,5964ms,6305ms,37390us,1907ms,1397ms,7490ms,1116ms,108ms,7415ms,1015ms,22992us
% sudo zpool destroy test
% sudo gnop destroy ada0.nop

おー。シーケンシャル書き込みだけ見ても68MB/sと15%以上もスループットが向上し、latencyも大幅に改善した。
さらに、2台でストライピングしてみるとこうなった。

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
daemon.musha.or 16G   138  98 94311  22 58070  12   431  99 123342  13 172.8   5
Latency               155ms    3874ms    4034ms   38783us     990ms     730ms
Version  1.96       ------Sequential Create------ --------Random Create--------
daemon.musha.org    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    64:102400:128/8  1123  29   134   1 16901  80  1062  27   111   1 18945  88
Latency              3282ms    1121ms   53040us    4831ms     910ms    4748us
1.96,1.96,daemon.musha.org,1,1271168105,16G,,138,98,94311,22,58070,12,431,99,123342,13,172.8,5,64,102400,128,,8,1123,29,134,1,16901,80,1062,27,111,1,18945,88,155ms,3874ms,4034ms,38783us,990ms,730ms,3282ms,1121ms,53040us,4831ms,910ms,4748us

シーケンシャルで94MB/s。不満は残るがとりあえずよしとしよう。
ところで、gnop(8)の設定は保存されないので、起動するたびに設定する必要がある（つまり、起動用のシステムを構成するボリュームでは使えないと思った方がよさそう）。というわけで、こんな風なスクリプトを書いて/etc/rc.d/に置き、

#!/bin/sh
 
# PROVIDE: zfs_prepare
# BEFORE: zfs zvol
 
. /etc/rc.subr
 
name="zfs_prepare"
rcvar="zfs_prepare_enable"
start_cmd="zfs_prepare_start"
stop_cmd="zfs_prepare_stop"
#required_modules="geom_nop"
 
zfs_prepare_start()
{
	[ `$SYSCTL_N security.jail.jailed` -ne 1 ] || return 0
 
	local dev
	for dev in $zfs_prepare_devs; do
		gnop create -S 4096 $dev
	done
}
 
zfs_prepare_stop()
{
	[ `$SYSCTL_N security.jail.jailed` -ne 1 ] || return 0
 
	local dev
	for dev in $zfs_prepare_devs; do
		gnop destroy $dev.nop
	done
}
 
load_rc_config $name
run_rc_command "$1"

/etc/rc.confに設定する。

zfs_prepare_enable="YES"
zfs_prepare_devs="ada0 ada1 ada2"

これで無事、nopデバイスが起動時にできるので、好きに使ってプールを構成すればいい。
外付け箱にはとりあえず3台積んでストライプし、内蔵している移行元HDDからのそこへのコピーが済んだら、古い内蔵HDD群を換装してada[0-2]にそれぞれattachすれば、RAID1+0のような構成になるだろう。空いたスロットには、起動ドライブのミラーボリュームを入れるつもり。
メンテナンスに入るときに、ホットスワップもテストしてみたい。夢が広がるよ！