ディスク遅杉ということで、いろいろ調べてみる。
raid0.conf は

START array
1 5 0

START disks
/dev/wd0a
/dev/wd1a
/dev/wd2a
/dev/wd3a
/dev/wd4a

START layout 
# sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level
16 1 1 5

START queue
fifo 100

となっている。キモなのはおそらく START layout の所の 16 である。
HDDは5ヶ、raid5なので、そのうちstripe毎にラウンドロビンでどれか1つがパリティ。
実質4台で1stripeを構成することになる。sector per stripe unit が 16 なので、
HDD1台が16sector*512byte=8kbyteのブロックに分かれ、これが4+1台分で32(+8)kbyte=1stripeとなる。
32kbyte未満でread/writeするとパリティ計算で余計なread/writeが増えるため、newfs -b 32768 等とすれば効率も問題なし…のはずなのだが、なぜか激遅。

同じような構成の別のマシン(こっちはdisk9玉)では、問題なく80Mbyte/secくらい出てるので、NetBSDのraidframeがタコというわけでもない。
なーぜーだーーーーー

sector per stripe unitやらnewfsのブロックサイズやらのパラメータを色々々々々々々々々々いじってみると、10M〜20Mbyte/secまで改善するものの、これでも遅い。
raidframeのソース読んだりパラメータ替えたりraidframe -Iしたりraidframe -Pしたりするが、結局改善せず、原因もわからないまま。うーん…


            §            §            §


ある日なんとなく思いついて、gptで定義したパーティション開始セクタを64にしてみと、劇的に改善。90Mbyte/secとか出ますよ。やったー。
つまりこういうことだ。

     raid0           wd0     wd1     wd2     wd3     wd4
     0〜 63  →     0〜15   0〜15   0〜15   0〜15   0〜15
    64〜127  →    16〜31  16〜31  16〜31  16〜31  16〜31
   128〜191  →    32〜47  32〜47  32〜47  32〜47  32〜47
      ：     →      ：      ：      ：      ：      ：

こんな風にアクセスされる訳だが、gpt で定義したパーティションは

# gpt show raid0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  7814100093      1  GPT part - NetBSD UFS/UFS2
  7814100127          32         Sec GPT table
  7814100159           1         Sec GPT header

であり、/dev/dk0 は

# dkctl /dev/rraid0d addwedge dk0 34 7814100093 ffs

となっていて、raid の 34セクタ目から始まる。
dk0 に対して newfs -b 32768 すると、dk0 に対して 32768バイト(=64sector)毎にread/writeするものの、
あくまでそれは dk0 に対してであり、dk0 の開始セクタが34である以上、アクセスパターンは

      dk0           raid0            wd0             wd1             wd2             wd3             wd4
     0〜 63  →    34〜 97   →  0〜15/16〜31    0〜15/16〜31    0〜15/16〜31    0〜15/16〜31    0〜15/16〜31
    64〜127  →    98〜161   → 16〜31/32〜47   16〜31/32〜47   16〜31/32〜47   16〜31/32〜47   16〜31/32〜47
   128〜191  →   162〜225   → 32〜47/48〜63   32〜47/48〜63   32〜47/48〜63   32〜47/48〜63   32〜47/48〜63
      ：     →      ：               :               :               :               :               :

となってしまっていたのだ。34〜97なんてブロックでread/writeされると、当然raidのストライプ2つ分をまたぐため、read/writeが二倍になり、劇的に遅くなっていた。
つまり gpt のパーティションを

# gpt add -b 64 -s 7814100063 raid0
# gpt show raid0
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34          30         
          64  7814100063      1  GPT part - NetBSD UFS/UFS2
  7814100127          32         Sec GPT table
  7814100159           1         Sec GPT header

のように64セクタ(raidのstripe size)から開始するようにすれば、ファイルシステムのアクセスがstripe単位で行われるようになって、万事解決ｳﾏｰ

これでやっとデータ移行作業に移れる…