ハードディスクを大容量のものに交換して密度が上がったせいか、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のような構成になるだろう。空いたスロットには、起動ドライブのミラーボリュームを入れるつもり。
メンテナンスに入るときに、ホットスワップもテストしてみたい。夢が広がるよ！

ドライブドア SATAボックスレイド EX35PM4B-PE

自宅のメインサーバとして、HP ML115 G5をFreeBSD 8/amd64で運用している。フルZFS構成で、大事なデータはraidz2プール内に置き、バックアップはsnapshotで取るようにして数ヶ月。snapshot作成に時間が掛かり、パーティショニングの柔軟性も低いUFS2に比べとても管理が楽になった。

まだHDD故障を経験していないが、（zfs send & receiveで別ディスクにバックアップを取った上で）わざと1台のデータを破壊してデグレード状態で動作すること、さらにもう1台壊してもちゃんと動くことまでは検証できている。
先日、netatalkでTime Machineサーバに仕立て上げ、何台かあるMacのバックアップを担わせるようにしたところ、残容量が非常に心許なくなった。さらに、おんぼろHDD 2台を活用して作ったNASの寿命もそろそろ心配になってきたのでファイルサーバも集約したいのだが、そうするには容量が圧倒的に足りない。
今ML115 G5に入っているのは、先々代のサーバから引き継いで使っているHGSTのDeskstar T7K500の群れだが、こいつらの低いゴリゴリ音は実によく響いてうるさい。設置場所はリビングルームの端、レンジ台の脇の隅っこだが、音はけっこう気になる。
ということで、大容量のHDDを新調して移行しようと決めた。停止時間を短くするには稼働中にデータコピーを行う必要があるが、USB 2.0に数台ぶらげて書き込むのはスループット的に難がある。ハードウェアRAIDを備えた箱もあるが、あまり期待はできない。移行後の使い出も考えた結果、最近のFreeBSDでは使えるらしいeSATA port multiplierに対応した外付けHDD箱を買うことにした。
価格が手ごろでeSATAインターフェースPCIeカードも付属しているというセンチュリー ドライブドア SATAボックスレイド EX35PM4B-PEを購入。事前の調べで付属のカードに載っているのはFreeBSDでも対応しているSiI 3132だと分かっていたが、port multiplierについては同じチップが載っていてもカードによって動かないものもあるという話もあり、また見つかる事例はSATAの話の方が多く、出たとこ勝負だった。
…が、動いたよ！OSバージョンは先月初旬の8.0-STABLEだが、たぶん8.0-RELEASEでも行けるだろう。（7.xは、MFCされていないのできっと無理）
何も設定しないとataドライバがSiI3132を掴んでしまって動かないので（最初気づかず絶望しかけた）、以下の行を/boot/loader.confに追加する必要がある。（あるいはdevice siisでカーネルに静的に組み込んでもいいだろう。probe後では遅い。）

siis_load="YES"

これで、以下のようにada0, ada1, ada2, ...として認識される。

Apr 13 22:02:57 daemon kernel: siis0:  port 0xef80-0xefff mem 0xfcfffc00-0xfcfffc7f,0xfcff8000-0xfcffbfff irq 16 at device 0.0 on pci4
Apr 13 22:02:57 daemon kernel: siis0: [ITHREAD]
Apr 13 22:02:57 daemon kernel: siisch0:  at channel 0 on siis0
Apr 13 22:02:57 daemon kernel: siisch0: [ITHREAD]
Apr 13 22:02:57 daemon kernel: siisch1:  at channel 1 on siis0
Apr 13 22:02:57 daemon kernel: siisch1: [ITHREAD]
...
Apr 13 22:02:57 daemon kernel: ada0 at siisch0 bus 0 scbus0 target 0 lun 0
Apr 13 22:02:57 daemon kernel: ada0:  ATA-8cd0 at ata7 bus 0 scbus7 target 0 lun 0
Apr 13 22:02:57 daemon kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Apr 13 22:02:57 daemon kernel: ada0: Command Queueing enabled
Apr 13 22:02:57 daemon kernel: ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
Apr 13 22:02:57 daemon kernel: ada1 at siisch0 bus 0 scbus0 target 1 lun 0
Apr 13 22:02:57 daemon kernel: ada1:  ATA-8 SATA 2.x device
Apr 13 22:02:57 daemon kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Apr 13 22:02:57 daemon kernel: ada1: Command Queueing enabled
Apr 13 22:02:57 daemon kernel: ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
Apr 13 22:02:57 daemon kernel: ada2 at siisch0 bus 0 scbus0 target 2 lun 0
Apr 13 22:02:57 daemon kernel: ada2:  ATA-8 SATA 2.x device
Apr 13 22:02:57 daemon kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Apr 13 22:02:57 daemon kernel: ada2: Command Queueing enabled
Apr 13 22:02:57 daemon kernel: ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
...

これで積めるHDDの台数制限がなくなったので、みみっちくraidz2するのはやめてmirrorの連結（いわゆるRAID1+0相当）にするつもり。
なお、HDDは見ての通り4KB sectorのWD15EARSなので、アラインメント問題が待ち受けている。それを含めた性能の評価と、期待のホットスワップの可否検証はまとまって時間が取れるときにするつもり。とりあえず動いてほっとした！（･∀･）！