以前のPentium Mのサーバは、FreeBSD9にすると起動してすぐにカーネルパニックを起こしてリブートループしてしまうため、8-STABLEを使用していた。
今回、サーバマシンが死んでCore i7マシンに変わったので、FreeBSD9にすることを検討する。
で、どうせ9系にするのならば、i386版ではなくamd64版にしたい。
一応、二つのスライスを利用した FreeBSD i386 から amd64 への移行: uyota 匠の一手と言うサイトを見て、stable/9をチェックアウトして、TARGET_ARCH=amd64をつけてやればアップグレードもできそうだと思ったんだけど、i386のライブラリが残るだとか、portsも全部ビルドし直した方が良さそうとかあるので、クリーンインストールすることに。
2TのHDDを購入して、新しいディスクをATA0に、古いディスクをATA1に繋いで、9.2-RELEASEのインストーラを起動。
現在のデフォルトはMBRではなくGPTらしいので、GPTでfreebsd-bootに128k、freebsd-ufs(/)に512G、freebsd-swapに8Gの領域を確保して、インストール実行。
あっという間に終わるので、再起動・・・・。
起動しません。
マシンを交換したときと同じ、

Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device and press a key 

が出るだけ。
何か間違えたかと思って、インストールDVDから起動し直してgpart show とかやっても正しそうに見える。
パーティションの切り方が悪いのかと思って、全部デフォルトでインストールし直しても同じ。
この時気になったのが、ATA1に繋いでいるはずの古いディスクがgpart showで正しく見えない。 dmesgを見ると、

GEOM_RAID: Promise: Array Promise created.
GEOM_RAID: Promise: Disk ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Subdisk PROMISE Array 1:0-ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Volume started.
GEOM_RAID: Promise: Volume PROMISE Array 1 state changed from STARTING to OPTIMAL.
GEOM_RAID: Promise: Provider raid/r0 for volume PROMISE Array 1 created.  

とか言って、promiseのraidコントローラと勘違いしている？
この時点で、OSが起動しない、古いディスクが読めない、と言う2つの大きな問題を抱えてしまった。
GPTとFreeBSDのbootシーケンス等についていろいろ調べたりして、pmbrを書いてみたり、gptbootを書いてみたりしたけど状況は変わらず。
面白いことに、古いHDDにあるmbrからブートすると、ブートメニューでF5を押して別のディスクを選択すると、GPTの新しいFreeBSDが起動する。
しかし、古いディスクをブートシーケンスに含むのは変だし、先々困りそうである。
ここで一度諦めて古いHDDからブートし、一晩頭を冷やすことにする。
頭を冷やしている間に、古いHDDがraidに見えてしまう問題について調べてみたところ、freebsd-stable - GEOM_RAID in GENERIC is harmful と言うのを発見。
FreeBSD 9-STABLEのどこかのタイミングで、GENERICカーネルにGEOM_RAIDオプションがデフォルト化され、それが原因で古いHDDを繋ぐとおかしいことが起きるよ、的な話らしい。
そこで、最初のサイトをヒントに、古い環境にstable/9のソースをチェックアウトし、amd64用のカーネルコンフィグを作成して、TARGET=amd64でbuildkernelし、新しいHDDに入れてみた。

include GENERIC

ident           FALSE

device crypto

options         IPSEC
#options                IPSEC_ESP
options         IPSEC_DEBUG
options         IPSEC_NAT_T
options         IPFILTER
options         IPFILTER_LOG
options         IPFILTER_DEFAULT_BLOCK
#options                TCP_DROP_SYNFIN
options         SHMMAXPGS=10000
options         SHMMNI=100
options         SHMSEG=10
options         SEMMNS=200
options         SEMMNI=70
options         SEMMSL=61

nooptions       GEOM_RAID

変更点は、最後のnooptions GEOM_RAID
これで、新しいHDDから起動してみると、無事に古いHDDをマウントして見ることができた。
その後、GPTのブートについていろいろ調べたがどうにも解決しなかったので、諦めてMBRでパーティションを作成してOSをインストール。
これで起動することができた。
再度古いHDDからinstallkernelして、今度は新しいHDDでbuildworld/installworldもやり直した。

今回のディスクも、以前のディスクも、AFT(物理セクタが4kiB)なので、パーティションも4KiB境界にあるのが望ましいらしい。(clicklog: FreeBSD 9.0-RELEASE インストールの練習)
gpartを使うと、勝手にやってくれそうな感じだけど、MBRでインストールした場合は勝手にやってくれなかったようだ。

# diskinfo -v /dev/ada0s1a
/dev/ada0s1a
        512             # sectorsize
        541165879296    # mediasize in bytes (504G)
        1056964608      # mediasize in sectors
        4096            # stripesize
        3072            # stripeoffset
        1048576         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WD-WMC4M1940446 # Disk ident.

diskinfo -v して、stripeoffsetが0か、4096の倍数であれば良いらしいのだが、見事に3072である。
そこで、FreeBSDでWD10EARSをMBRで使う際に本来の性能を出す方法 - mteramotoの日記を参考に504(63と8の最小公倍数)の倍数をstart sectorとするパーティションを作成し、上記ada0s1aとシーケンシャルread/writeでの速度比較を行ってみた。
結果としては、新しくアラインメントを合わせて作った ada0s2 の方が、アライメントがあっていないada0s1よりも気持ち遅い、と言う結果になった。(以下で、/varがインストーラが作ったパーティションで、/mntが自分でアライメントを合わせて作ったパーティション)
実験1: /dev/randomからHDDにddで約40Gコピー

# dd if=/dev/random of=/var/test.dd bs=4k count=10000000
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 453.281270 secs (90363319 bytes/sec)
# dd if=/dev/random of=/mnt/test.dd bs=4k count=10000000 
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 419.405037 secs (97662156 bytes/sec)

実験2: HDDからHDDにddで約40Gコピー

# dd if=/var/test.dd of=/var/test2.dd bs=4k
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 905.631041 secs (45228132 bytes/sec)
# dd if=/mnt/test.dd of=/mnt/test2.dd bs=4k
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 1377.528304 secs (29734416 bytes/sec)

稼働中のサーバなのである程度の誤差はあるが、アライメントを合わせた方がread/writeでは明らかに遅い。
これは、実験1では純粋なシーケンシャルwriteなのに対し、実験2はread/writeで間にシークが入るので、ディスクの場所(内周/外周)による差が出やすいのではないかと思ったりしている。
結局、実運用では気にするようなパフォーマンスの差はないのではないかと結論し、パーティションを作りなおして再インストールはしないことにする。(実験1はアライメントを合わせた方が速いので、今から入れる人は504の倍数に合わせた方が良いかも)

この後いろいろインストールして、rrdがアーキテクチャの違いで読めないとか、pptpが繋がらないとかあったけど、それはまた気がむいたら別の機会に。