[過去ﾛｸﾞ] /**ファイルシステム総合スレ その1**/ (979ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
900: 03/07/19 05:46 ID:k1TgDB/w(2/2) AAS
>899
FreeBSDのRAIDFrameはとりあえず動くようにしただけのAlphaコードなので
vinum使ってくだちい。
901(3): 03/07/21 03:49 ID:9Pl9AQ8J(1/2) AAS
vinumでやりました。
KB reclen write rewrite read reread ran-read ran-write
ufs2 softupdate:
524288 64, 6021 6139 385297 385258 1053495 1058699
524288 128 6040 6072 261972 262179 460757 323863
524288 256 6000 6079 214404 214565 251672 227241
16777216 64, 5885 5944 23063 23061 1226402 1049510
16777216 128 5885 5964 22499 22478 454099 347115
16777216 256 5871 5957 22270 22256 243563 218161
書き込みが非常に遅いですが読み込みは普通に速いです。
省13
902(1): 03/07/21 03:51 ID:9Pl9AQ8J(2/2) AAS
あ、ファイルの作成はreiserfsのほうが速いや
903: 03/07/21 07:27 ID:J1Ol9sQd(1/2) AAS
Codaファイルシステム、みんな使ってますか？
外部ﾘﾝｸ:www.coda.cs.cmu.edu
Windows用のクライアントの最新バージョンって、
バイナリがないんですかね？
904: 03/07/21 12:30 ID:J1Ol9sQd(2/2) AAS
OpenAFS とかの分散ファイルシステム関連のスレッドってありませんか？
905: 03/07/21 20:22 ID:8Ie/P7G+(1) AAS
>>901
こりゃまたごっつい結果が出ましたなあ。
どうもこれを見るに、ファイルシステムの違いよりもRAIDの違いの方が大きそう。
vinumは「漢はランダム(=シーケンシャルはうんこ)」という信念に基いた設定が
デフォルトなのでそこが全面に出てきているのではないかと。
逆にLVMはシーケンシャル命(=ベンチマーカーが喜ぶ)設定が
デフォルトなので>>895のような数字になったと考えます。
906(1): 03/07/21 23:59 ID:YVvmD1eO(1) AAS
>>901
おつかれ〜。面白いねぇ。
一応確認しますが、
>>901 の
＞bonnie++ -s 16g -n 100:50k -r 640のlfsでの結果。
は、ufs2 + softupdate での結果、でよろしいでしょうか？
>>902
CPU 負荷がだいぶ違いますが、とりあえず seq create per CPU1% で見てみても、
reiserfs 54.1
ufs2soft 34.5
省7
907(1): 901 03/07/24 12:33 ID:APm+ETGG(1) AAS
>906
＞ufs2 + softupdate での結果、でよろしいでしょうか？
はい。ufs2softって表にも書いた通りです。
で、あの結果を見ても分かる通り、16Gをランダムに書いて
1G/sとか有り得ない数字(例えば100MB/sで4台に書けたと
仮定しても、100*3で300MB/sが限界)が出てます。で、Don
に質問してみた所、FreeBSDではsrandつかってるからね、
srand48使うようにしてみて、などと返事されました。
そんなわけで、ちょっとFreeBSDはやり直してみてます。
908: 03/07/25 12:49 ID:NH3LXVfX(1) AAS
(･∀･)renice!
909(1): 03/07/25 16:37 ID:6G+OftYd(1) AAS
KB reclen write rewrite read reread ran-read ran-write
ufs2 softupdate with srand48:
524288 64, 5945 6074 382950 383263 326817 4574
524288 128 5940 6036 270864 269598 241653 4847
524288 256 5953 6015 217652 217670 207503 5067
16777216 64, 5890 5951 23225 23217 4470 2578
16777216 128 5882 5986 22673 22679 7086 3397
16777216 256 5885 5991 22339 22401 9197 3795
とまぁ普通の結果になりました。残念。
rand()の性能悪すぎ＆randの性能にこうまで依存してたiozoneちょい間抜け。
910: 03/07/26 00:11 ID:qll5XMfc(1) AAS
>>909
> randの性能にこうまで依存してたiozoneちょい間抜け。
それは仕方ないと思うんだけど、
> rand()の性能悪すぎ
>>907
> FreeBSDではsrandつかってるからね、srand48使うようにしてみて、
はどうしてなんだろ? glibcのmanだと、
> 注意事項
> これらの関数はSVID 3によって時代遅れと宣言されている。 SVID 3 はrand(3)
> が代わりに使用されるべきだと記述している。
省1
911: 03/07/26 01:46 ID:L1oQpf1J(1/5) AAS
iozoneをfreebsd対応した時代には、まだsrand48がなかったのか、
それとも対応をした人が面倒くさがってsrand48があるかどうか調べなかったのか、
そのどっちかでしょう。convexとMaxOSXで同様な問題を抱えてますw
いくらOSXがFreeBSDの派生だからといって、
そのまま流用するこたぁないと思うんですけどね。
912: 03/07/26 07:58 ID:Vorekzgd(1) AAS
つーか、FreeBSDのrand/srand(3)は古〜いままなんでは?
下位bitが余りランダムじゃない奴。えー加減にしろや
913(2): 03/07/26 13:18 ID:4eaeCEsA(1/2) AAS
FreeBSD 5.1R だと rand(3) は書き換えられてますよ。
make で USE_WEAK_SEEDING を定義しておくと古い rand になるようですが。
914: 03/07/26 16:38 ID:L1oQpf1J(2/5) AAS
>913
そうなんだ。不思議だね。ってことで調べてみた。確かに、古い
next = next * 1103515245 + 12345) % ((u_long)RAND_MAX + 1
系の乱数ではないね。iozoneでやけにパフォーマンスが良くなる
最小の数字が64だったのでそれで分散具合を調べてみた。
FreeBSD 5.1の「よりよいrand()」でrand()%64を64回計算すると、
0:1, 1:2, 2:3, 3:1, 4:2, 5:0, 6:1, 7:1, 8:0, 9:1, 10:3, 11:0, 12:1, 13:0, 14:5,
15:2, 16:1, 17:1, 18:0, 19:1, 20:0, 21:1, 22:0, 23:2, 24:0, 25:1, 26:3, 27:0, 28
:2, 29:1, 30:0, 31:1, 32:2, 33:2, 34:1, 35:0, 36:0, 37:1, 38:3, 39:0, 40:0, 41:1
, 42:1, 43:1, 44:1, 45:1, 46:0, 47:1, 48:0, 49:0, 50:0, 51:1, 52:3, 53:1, 54:2,
省3
915: 03/07/26 16:45 ID:L1oQpf1J(3/5) AAS
ちなみにLinuxだと
0:0, 1:1, 2:2, 3:0, 4:0, 5:1, 6:3, 7:1, 8:0, 9:1, 10:1, 11:0, 12:0, 13:4, 14:1,
15:0, 16:0, 17:2, 18:0, 19:0, 20:3, 21:0, 22:0, 23:1, 24:2, 25:0, 26:3, 27:2, 28
:1, 29:1, 30:1, 31:1, 32:0, 33:1, 34:0, 35:3, 36:0, 37:1, 38:1, 39:2, 40:1, 41:3
, 42:0, 43:2, 44:1, 45:0, 46:1, 47:0, 48:0, 49:1, 50:3, 51:2, 52:2, 53:0, 54:1,
55:1, 56:1, 57:0, 58:1, 59:1, 60:1, 61:1, 62:0, 63:1,
んでlrand48だと
0:1, 1:1, 2:0, 3:1, 4:3, 5:1, 6:2, 7:1, 8:2, 9:0, 10:1, 11:4, 12:1, 13:1, 14:1,
15:1, 16:1, 17:1, 18:2, 19:0, 20:1, 21:1, 22:0, 23:0, 24:1, 25:1, 26:1, 27:1, 28
:2, 29:1, 30:1, 31:0, 32:2, 33:1, 34:1, 35:2, 36:1, 37:0, 38:2, 39:0, 40:0, 41:3
省9
916(1): 03/07/26 16:58 ID:L1oQpf1J(4/5) AAS
……てゆーか、iozoneすげえバグってる＿|￣|○
917(1): 913 03/07/26 17:00 ID:4eaeCEsA(2/2) AAS
*rand48 系は乗算が多いから遅いのも。
rand(), random(), mrand48(), arc4random() で
ベンチマーク取ろうと思ったら、
よく考えると VMware で動いているんだった。意味ねぇ…。
>>916
どーした!?
918: 03/07/26 21:01 ID:L1oQpf1J(5/5) AAS
>917
Donはrand()が16ビット精度だと思ってるらしく、
2回rand()して結果を繋いでるんだけど、そのコードががが、、、＿|￣|○
big_rand=(rand1<<16)||(rand2);
おい、||じゃなくて|だろ……。Donにはメイルしますた。
lrand48()なOSには関係ないので上の結果はまあそこそこ信用できます。
あと、取り敢えずMersenne Twister使って、かつある程度自然に分散
するよう最低限X回random testでアクセスするように変更しすることで、
MTのランダム関数がちょっと偏ってても平気なようにして、
そのパッチを送りますた。
919: 03/07/26 22:02 ID:UPUujWHc(1/2) AAS
うーむ、常に精度が 16bit しかない…
しかし何時からあったんだろね、そのコード。
L1oQpf1J よくやった。感動した。w
いや、まじお疲れ様です。
上下前次1-新書関写板覧索設栞歴
あと 60 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s