ふしおにおが速い理由は間にSATAやSASといったディスク前提の遅延が大きいインターフェイスを使わないこと、あとCPUとNANDフラッシュチップの間にあるマイコンの数が少ないこと。さらに、普通は組込マイコンでやる処理をホストCPUでやっている点 ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:22:05PCI Expressを使えば速いというのは厳密には間違いで、そういう意味ならどんなアレイコントローラも今はPCIe経由でつながっているからね。PCIeを無駄なく使っている点や、PCIeの先にあるデバイスの応答性がレイテンシの改善につながっている ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:23:152.5インチやPCIeの物理形状でまともに廃熱もできないような場所に組み込みコントローラをおいても、大したことはできない。でも今のホストプロセッサは恐ろしいほどのパワーをもっているから、そこで処理をするとフォームファクタの限界を超えられる ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:26:33CPUにはDRAM用のコントローラ回路がのっている。ふしおにおはCPUからPCIe経由でフラッシュに直接アクセスできる仕組みだけ用意しておいて、OS側でフラッシュのメモリ空間を管理するVMMのエクステンションと、ブロックエミュレータを実装したもの ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:29:35第一世代ふしおにおは39bit ECCを使っている。ブロックあたり39ビット化けてもエラー訂正ができるのだ。その上にHDDの代替セクタ的処理やウエアレベリング、RAID-4的な訂正、ZFSライクなエンドツーエンドのエラーチェックなど何重ものロジックがXeonなどの上で動いている
2012-06-09 12:34:08あのパフォーマンスを出しつつ止まらないでいられるのは、ホスト側のCPUを使ってこれだけ複雑なことをしているから。これが逆に負荷になるのでは?→iowait 10%=CPUが0.1秒 I/O待ちで止まってるぐらいなら、その分だけで十分超えられる。 ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:37:06昔サンが不具合のあるハードウェアへの対処として訂正をソフトウェア側で補完していたものがあるらしい。複雑な組込ハードウエアは信頼性を担保するのに苦労するから、最初からハードはシンプルにして実績あるシステム上でモノを動かしたほうが効率がいい。 ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:49:00今、IA-32のサーバが演算を間違えることがあるなんて誰も思わないよね。しかし基板の上にマイコンをおいたら、それに対する信頼性の担保にはすごい手間がかかるし金がかかり、ソリューションとしてのコストも高くなるのだ ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:50:46昔はタイムシェアリングシステムとかで、いかにユーザにCPU時間を割り当てできるかが大事だったから、SCSIなど、マイコンへのオフロードが当たり前にされていた。でも今は逆にメインのプロセッサが高速化し、バランスが逆転している。だからホスト処理がいい ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:53:05技術的観点からのふしおにおのすごさはそんなかんじ。まあこんなことお客さんに言っても「へぇ〜」っていわれるだけで買ってもらえないから言わないけどw ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 12:55:13ふしおにおを高いと思うのならエンタープライズ向けでNANDフラッシュを酷使するのはあきらめてもいいんじゃないかな。iPadとかに入っているのと同じレベルのパッケージを搭載していつつも無駄なマイコンなしで最高峰の性能、これ以上のバランスはないだろう ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 13:01:05まあ私だって入社時点でここまでわかってた訳じゃなくて仕事してモノを見ているうちに色々わかってきたのだ。「これはメモリだわ」と ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 13:08:09まあそんなわけで、こんなデバイスを膝にうけて「ふしおにお刺したらI/O以外のボトルネックが露呈してこまってます!スワップしだしました助けて!」とかの駆け込み寺になってみてもいいという人は、こっそりDMかメールもらえれば将来お声がけするかもしれない ゚✧.(●⁰౪⁰●)゚✧.゚
2012-06-09 13:12:39