mikuフリーズしますね。(汗)
どうもSATAディスクのアクセスが、下手なようです。
ちょっと前から、ZFSのネイティブ版？（ただし非GPL）ということで、
ZFS on Linuxのテストをして、様子をみていました。
SSDをたくさん…は積めないのですが、ストレージの性能がどうにかほしくて
あのZFSなら、業務用のストレージのようなすごい機能も使えてイイネ！(ﾟ∀ﾟ)
…と思っていたのですが。
ちょっと使い物になっていません。。
単発ベンチマークではこんな数字はでるんですよ。 
ただ…
これでちょっとディスクアクセスを続けると、なんと。
I/O Waitが８０％オーバーに、
LoadAvgが60.0を超え、
ストレージ操作がタイムアウトしまくり。
になってしまいます。
※このサーバーはNehalemのXeonで計8C/16T、メモリ24GBを搭載。
上記マシンはZVOLでRAWデバイスを割り当てたKVMの仮想マシンのWindows10（TP）の図。
同様にZVOLを使い、iSCSI経由のブロックデバイスとして割り当ててVMwareに
見せてみると…たいして負荷もかけていないのにストレージアクセスが止まり、
OSごとダウンしてしまいました。
これも原因はI/O WAITで、見たこともないようなレイテンシで10分近く無応答…
というような「わけのわからない」状態になりました。
LSIのMPTドライバもあやしいのですが、いろいろ試した限りでは、
「SATAのHDD/SSDを使って」いて、「IO負荷をかける」とだめでした。
そう、SASディスクではこのような負荷にはなりません。
これはどうやら、SATAの「NCQ」との相性（というかI/Oの出し方が下手）なようで、
SASのTCQではうまくハンドリングができていて、うまく動くようです。
ZFSがらみのFAQなどでも、「I/O WAITが高すぎてフリーズするんだけど…」
という報告がちらほらあるものの、あまり相手にされていなくて。
唯一見つけたこの記事でも、どうもSATAがだめらしいと分かってきた次第。。
ZFS Slow Performance Fix – Letsgetdugg
http://letsgetdugg.com/2009/10/21/zfs-slow-performance-fix/
どうやらもともとのZFSの系譜をたどると、OpenSolarisではよくあった話の様子。
この記事によれば、zfs_vdev_max_pending を設定すればよいのですが、
なんと、最新のZFS on Linux（0.6.4）でこのパラメータはなくなっていて、
別のいくつかのパラメータに置き換わっています。
ざっとあげると、
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_max_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
このぐらい、あります…(汗)
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_write_active_min_dirty_percent
というのも関係ありそうです。
（man zfs-module-parametersで参照可）
ですが、いろいろ設定してみても、I/O WAITは改善できていません。
もう少し悩んでみるつもりですが、なかなか根の深い問題かもしれません。
ZFSのMailing List（英語）にも参加してみたので、
同じような超絶I/O WAITで困っている症状の方がいたら、
便乗して食いついてみたい…とは思っていますが、英語はだめなのでwww
いやはや、低コストで、爆速なIOパフォーマンスと、
超絶高度なストレージ機能が全部ほしい！
って話なので、贅沢すぎるのかなぁ。
本家Solarisのx86版ではどうなのでしょうね。
OracleのSunストレージ（業務用）はそれ動いているはずなので、
そっちのZFSを一度動かしてみるのもありかもしれません。
気になる方には気になる世界だと思うのですが…(苦笑)
また情報仕入れてレポートしてみたいと思います。
（といいながら、このまま消えてしまいそう。。）