测试的结论是，FreeBSD现在缺乏稳定而且高效率的Filesystem让MySQL MyISAM使用。
先解释一下现在的环境，有两台Tyan Server，上面都是Dual Quad Core与12GB RAM (6*2GB)，接两颗73GB SCSI硬碟，两台的差异在于CPU，新进的这台是E5410 ( 2333Mhz，2*6144KB L2)，旧的是E5320 (1866Mhz，2*4096KB L2)。
旧的是目前PIXNET production的MySQL database，跑Debian/amd64，kernel是2.6.22，档案系统是XFS。另外一台则是前阵子另外进的，装了FreeBSD/amd64 7.0-BETA2，然后透过make kernel & make world升级到7.0-PRERELEASE，跑SCHED_ULE，档案系统是UFS2。依照惯例，noatime与nodiratime之类的参数都会设上去，两台都是跑MySQL 5.1.22-rc，都是MySQL slave。
要复制slave很简单，把production停机(利用使用者比较少的时候，其他的slave会负责这台本来的事情)，整个目录复制一份到新的FreeBSD上，改server_id后跑起来后MySQL会跟master更新。
然后用databases/mytop看replication delay的情况(原版的mytop没有这个讯息，这是FreeBSD ports patch的功能)，发现即使是放着跑replication sync，某些时候UPDATE的速度反而会跟不上master，跟不上时的I/O是满载的(透过gstat看的)
目前测过最好的情况是这样跑：gstripe -s 16384将da{0,1}串起来，用async noatime。其他的情况包括：
gstripe -s 16384 gjournal async noatime：日志类的Filesystem在DB这类用法的速度不会提升，与预料的差不多。
gstripe -s 16384 soft updates noatime：毕竟要维持consistent，速度慢一些。
单颗硬碟 async noatime：也如同预期的，速度只有一半。
以效率来看，短期内还是会跑Debian/amd64养MySQL。
另外补充一点，本来是在开启gjournal的情况下用rsync把资料复制到本机，结果发生kernel panic，后来是先复制完再使用gjournal，这个部份还要到其他机器看看到底是怎么一回事。
