GLAN TANK三日目
NICが変です。GLAN TANKの方では無く、Myマシンの方。nForce SLIで通信すると、GLAN TANK側でエラーパケットがたくさん検出されて、ドロップされている。Mervell 88E8001の方だと、エラーパケット無し。
ということで、昨日の結果はあてになりません（汗
今日はMervell 88E8001の方で繋げてベンチマークしてみました。
昨日の結論「NFS4、そんなに速くない」とありますけど、プロトコルが変わったところでネットワークのスループットは変わっていないわけで、シーケンシャルなリードやライトの速度が劇的に変わるなんてことは当然無い、と思われます。NFS4の何が良いかといえば、多数のクライアントが接続してきたときの威力でしょう、おそらく。試したこと無いし、試せる環境が無いですけど…。
NFSのオーバーヘッドが無かったらどのくらいの速度が出るのか、ということで、いつものNBDでやってみました。Maxtor HDD 300GB ×2 -> IDE -> XScale IOP 400MHz -> Linux 2.6.10 -> ソフトウェアRAID 1 -> ext3 -> nbd-server -> Intel PRO/1000-> カテゴリ6ケーブル -> Mervell 88E8001 (1000BASE-T) -> Linux 2.6.15.1 -> nbd-client -> ext3
GLANTANK# dd if=/dev/zero of=/ndisk bs=1M count=4096
GLANTANK# ifconfig eth0 mtu 9000
GLANTANK# nbd-server 4000 /ndisk
vcore# ifconfig eth0 mtu 9000
vcore# nbd-srever GLANTANK.local. 4000 /dev/nbd0
vcore# mkfs.ext3 /dev/nbd0
vcore# mount /dev/nbd0 /mnt/tmp
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vcore 2G 12055 32 12056 9 3641 2 10213 33 11705 5 133.3 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2658 94 +++++ +++ 30434 96 2412 95 +++++ +++ 5591 83
vcore,2G,12055,32,12056,9,3641,2,10213,33,11705,5,133.3,0,16,2658,94,+++++,+++,30434,96,2412,95,+++++,+++,5591,83シーケンシャルライトが12MB/s、シーケンシャルリードが12MB/s…かも。NFSとあんまり変わらない…。ネットワークのスループット自体がこれくらいということでしょうか（HDDのアクセス速度がボトルネックかもしれないけど…それは無いと勝手に思い込む）。でもCreateの方は圧倒的に速いです。NFSと違って、ファイルを作ったときに「作ったよー」とサーバー側にすぐに伝えなくて良いからだと思われます。NFSは、他のクライアントと協調を考えてあるから、ここでバッファリングしちゃいけないのではなかろうか…。NBDはそのあたり無視ですね。ファイルシステムはext3なので、ロック処理などは自カーネルの中で完結して、サーバーと通信しません…たぶん。
バックアップ用として考えたら、NFSの方が良さそう。ローカルでバッファリングしないで、すぐサーバー側に送信して欲しいから。
VIVERで使うなら明らかにNBDが良いですね。速度的には。VIVERはサーバーに書き込み要求しないから、ロックは要らない。
ただし、NFSに置いた巨大なファイルをループバックマウントして、ルートファイルシステムに使うのはアリだと思います。シーケンシャルリードはあまり変わらないから。NBDを持たないカーネル(=Linux以外)に移植しようと思ったら、この方法になると思います。
FreeBSDはブートローダがNFSに対応しているというすさまじいことになっているので(というか、Solarisもそうで、そうじゃないのはLinuxくらいらしい…)、NFS-RootにLinuxでいうところのinitrdの中身を置いておき、同じくNFS-Root上に置いておいた巨大なディスクイメージをループバックマウントする、という方法が、VIVERの移植方法としてもっとも現実的だと思います。これに圧縮ブロックデバイスとハードウェア自動検出機能があれば、移植完了。
分散ブロックデバイス共有のFreeBSD版を作るのが最高ですけど…。
