トップページ⇒unix
1001コメント309KB

[次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ]

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/05/03(水) 13:41:10
[次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ]
次世代ファイルシステムとしての期待が高いZFSにAppleが興味を示しました。
10.6か10.5で搭載されると見られるこのZFSについて語りましょう。

Solaris ZFS
http://www.sun.com/software/solaris/zfs.jsp

OpenSolaris
http://www.opensolaris.org/os/
0048名無しさん＠お腹いっぱい。2006/05/04(木) 15:49:16
ん? ZFS も ufsdump コマンドでバックアップしたい、という話?
それは知らんが... そんな愛着あるわけ?w
0049名無しさん＠お腹いっぱい。2006/05/04(木) 17:35:35
>>47
カプセル化した場合でしょ。
VxFSネイティブはHP-UXならvxdumpがある
Solaris用にそれがにあるか知らんけど
0050名無しさん＠お腹いっぱい。2006/05/04(木) 21:31:08
LFSでは対抗できませんかそうですか。
0051名無しさん＠お腹いっぱい。2006/05/04(木) 22:49:09
FFS, FFFS, LFS と来て ZFS ならあなたのファイルシステム人生はカンペキです。
ZFS 移行後は LFS は Sprite で使ってあげてください。
0052名無しさん＠お腹いっぱい。2006/05/05(金) 00:28:19
もう半年くらい使ってるけど
リストアらくちんでイイね。

ファイルシステムもリストア掛けたらつくってくれるし。
俺のデスクトップ程度で使ってる程度じゃトラブルないし。
0053名無しさん＠お腹いっぱい。2006/05/05(金) 00:36:26
キタキタ
http://www.itmedia.co.jp/enterprise/articles/0605/04/news009.html
0054名無しさん＠お腹いっぱい。2006/05/05(金) 00:49:35
>>52
使ってる人キタ━━━━━(゜∀゜)━━━━━!!!!
よかったらベンチマークとかしてみてくれませんか？

ディレクトリやファイルを10000個とか作ったり、
100KB程度のファイル1000個に書き込んだり、読み込んだり、
1GB程度のファイルを書き込んだり、読み込んだり。

誰かベンチマーク用のいいソフト知りませんかー？
もしくはベンチマーク用のスクリプト書いて〜。
0055名無しさん＠お腹いっぱい。2006/05/05(金) 01:10:05
>>53
＞UNIX File Systemsの代替として最適だとしている。

・・・・ん、あ、ufsかｗｗｗ
0056名無しさん＠お腹いっぱい。2006/05/05(金) 03:11:50
>>25
>>29

ライセンス的には、GPLのLinuxカーネルにCDDLのZFSを
そのまま持ってくるのは難しい。
そのため、互換コードを作成するしかないみたい。
↓この辺りを読んでみるといいかも。
http://www.opensolaris.org/jive/thread.jspa?messageID=25633？
http://www.gnu.org/licenses/license-list.ja.html
http://d.hatena.ne.jp/kinneko/20060502/p12

ベンチマーク情報はこの辺りみたい
ZFS and RAID-Z benchmark results vs. ext3 and XFS with Linux SW RAID-5
http://www.opensolaris.org/jive/thread.jspa?messageID=19368？
0057名無しさん＠お腹いっぱい。2006/05/05(金) 05:13:57
LeopardではZFS 128bit FileSystem採用が最大の話題だね

ZFSは最初からデータの書き込み中にOS落ちたりすることを前提に作ってるから、
ジャーナリングとかの中途半端な仕組みは要らない。
いつHDのケーブルを引っこ抜こうとも、ファイルシステムは正常な状態ってこと

つまりfsckみたいなエラーリカバリのphaseを作らなくても
次の稼働中に前回落ちたときのトランザクション分はロールバックされるわけだ
ロールバック対象前はファイルがファイルシステムによってロックされている

DB分かる人なら、トランザクションの考え方と同じだよ

クライアントで使うメリットを考えると、
これからのSATA/eSATAとかのホットプラグに対応したHDを使うにはうってつけ
ボリュームプールでパーティションの容量を好きなように変更できるのもいい
LinuxのLVMみたいな機構をファイルシステムレベルで実装したってことだね
ファイルシステムレベルでRAID機能持ってるのもいい
チェックサムでデータが壊れないってのもいい
暗号化でノートPC盗まれても安心だ

スナップショットはクライアント環境ではいらないと思う
主にDBサーバのバックアップとかに使う技術だから
0058名無しさん＠お腹いっぱい。2006/05/05(金) 05:24:00
http://en.wikipedia.org/wiki/Comparison_of_file_systems
0059名無しさん＠お腹いっぱい。2006/05/05(金) 07:05:09
>>57
> ジャーナリングとかの中途半端な仕組みは要らない。
&
> DB分かる人なら、トランザクションの考え方と同じだよ

…
0060名無しさん＠お腹いっぱい。2006/05/05(金) 07:11:57
>>57
OpenBSDにはうってつけだな。
0061名無しさん＠お腹いっぱい。2006/05/05(金) 07:55:31
>>LeopardではZFS 128bit FileSystem採用が最大の話題だね

Leopardで採用するなんて誰か言ったか…？
0062名無しさん＠お腹いっぱい。2006/05/05(金) 09:17:51
>>57
コピペうぜえ
0063名無しさん＠お腹いっぱい。2006/05/05(金) 09:39:39
% time mkfile 10g tmp
0.03u 25.07s 7:09.92 5.8%

まぁそもそもうちはDISKがはやく無いからなぁ・・・
[ID 640982 kern.info] IDE device at targ 1, lun 0 lastlun 0x0
[ID 846691 kern.info] model ST380011A
[ID 479077 kern.info] ATA/ATAPI-6 supported, majver 0x7e minver 0x1b
[ID 228648 kern.info] ata_set_feature: (0x66,0x0) failed
0064名無しさん＠お腹いっぱい。2006/05/05(金) 10:17:38
http://pc8.2ch.net/test/read.cgi/win/1087779601/837
http://pc8.2ch.net/test/read.cgi/win/1144321927/611
http://pc8.2ch.net/test/read.cgi/unix/1146631270/57
http://pc7.2ch.net/test/read.cgi/pc/1145100048/349
http://pc7.2ch.net/test/read.cgi/pc/1144887195/522
http://pc8.2ch.net/test/read.cgi/win/1145027419/870
0065名無しさん＠お腹いっぱい。2006/05/05(金) 10:30:41
>>58
なんで、ZFS(16EiB)がUFS2(1YiB)に、
ボリュームサイズが負けてるのかと思ったら、
ZFS can store 16 Exabytes in each storage pool, file system, file, or file attribute.
これなのね。
0066名無しさん＠お腹いっぱい。2006/05/05(金) 11:33:11
もうLinux駄目駄目だな
0067名無しさん＠お腹いっぱい。2006/05/05(金) 12:05:04
LinuxよりMacOS Xの方がTCO安いからね
0068名無しさん＠お腹いっぱい。2006/05/05(金) 12:14:21
MacOS Xはハードが縛られるから、それさえなければいいと思う。
俺は、Solarisでいいや。
0069名無しさん＠お腹いっぱい。2006/05/05(金) 12:14:53
>>57
私の発言を集めて編集してあちこちに貼り付けるとは…。
ちょっと複雑な気分。

> DB分かる人なら、トランザクションの考え方と同じだよ

ここは誤解を招きやすいから元スレでもツッコミが入った。

> スナップショットはクライアント環境ではいらないと思う

ここは元スレで、クライアント環境でもウイルスとかに感染した場合に有効だって話が出た。
0070名無しさん＠お腹いっぱい。2006/05/05(金) 12:18:06
>>57
> LeopardではZFS 128bit FileSystem採用が最大の話題だね

Mac OS X 10.5(Leopard) には間に合わないと思う。
10.5って今年末〜来年頭ぐらいのリリース予定だったはず。
0071名無しさん＠お腹いっぱい。2006/05/05(金) 12:34:50
そもそもUFSじゃまともに動くかんアプリ多いし。
Microsoft Office for Macもその一つ。
0072MACオタ＞71 さん2006/05/05(金) 14:09:19
>>71
　　--------------------
　　そもそもUFSじゃまともに動くかんアプリ多いし。
　　--------------------
その理由の大半わ､「"case sensitive"じゃないことを前提にしている｣ってだけでFSの仕様と関係無いす。
0073名無しさん＠お腹いっぱい。2006/05/05(金) 14:45:58
>>72
違うよ。
コテで無知晒すのって恥ずかしくない?
0074名無しさん＠お腹いっぱい。2006/05/05(金) 15:01:07
あちこちで恥さらしまくってるからいまさらって感じでしょ。＞ MACオタ
ここ数日だけでも、Intel次世代スレとかAMD次世代スレとか
CPUアーキスレとかで、あからさまな間違いを指摘されまくってるし。
0075名無しさん＠お腹いっぱい。2006/05/05(金) 15:04:59
そっか。
MacもSolarisと同じくエンディアンの問題があるんだな。
MacのHFS+やUFSがCPUのエンディアンによってフォーマットが変わるのかどうか知らんが。
0076MACオタ2006/05/05(金) 15:21:38
>>73 さん
そうすか？多くのクロスプラットフォームアプリわ､もはやリソースフォークを持たないし特に問題が
おきる理由も無い筈すけど。。。

>>74 さん
あちこちで印象操作ご苦労様す。決して具体例わ指摘できないようすけど(笑)

>>75 さん
UFSわエンディアンでフォーマットに互換性が無くなるとのことす。
http://docs.sun.com/app/docs/doc/819-0386/6n2qla469?a=view
　　-------------------------
　　PARC と x86 とでは UFS フォーマットが異なります。SPARC はリトルエンディアンによるビット
　　コーディング、x86 はビッグエンディアンによるビットコーディングを採用しています。UFS 用に
　　フォーマットされたメディアは、それらがフォーマットされたハードウェアプラットフォームに制限されます。
　　-------------------------
0077名無しさん＠お腹いっぱい。2006/05/05(金) 15:39:14
変なのが湧いてきたな…
0078名無しさん＠お腹いっぱい。2006/05/05(金) 15:44:22
SolarisのUFSに互換性が無いのはしっとるがな。
MacのUFSの話だがな。
0079名無しさん＠お腹いっぱい。2006/05/05(金) 15:57:10
MACオタの間違いの具体例？
・CPUアーキスレ
　英文Webページの内容を誤読。ページに書いてあることを書いてないと勘違いして
　AMDを中傷。
  http://pc7.2ch.net/test/read.cgi/jisaku/1139046363/593-595
・AMD次世代スレ
　PC Watch の後藤氏の記事を誤読。
　記事に書いてないことを、書いてあると思い込み、後藤氏を馬鹿呼ばわり。
  http://pc7.2ch.net/test/read.cgi/jisaku/1145187468/118-130
・Intel次世代スレ
　数日の間に、山のような間違いを書いたので、いちいち指摘しきれんが、
　いくつかを挙げると、
　・MPPマシンはメモリ共有アーキテクチャだと主張。
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/664
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/670
　・MPP⊃HPCクラスタ という記述を MPP=クラスタ だと誤読。
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/774
　・調査会社のガートナーの名称をカートナーと勘違い。
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/774
　・SR8000を大規模SMPだと主張。
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/787
・SMPクラスタと大規模SMPの区別をつけられないことを露呈。
    http://pc7.2ch.net/test/read.cgi/jisaku/1144400151/787

具体例を指摘できないと思ってるってことは、MACオタは、上のような
自分の間違いを、いまだに間違いじゃないと信じてるってことなのかな？
0080名無しさん＠お腹いっぱい。2006/05/05(金) 16:06:41
4.2BSD のもともとの ufs のコードは、エンディアン依存性のあるもの
だったが、そこから派生した各ベンダの実装が、エンディアン依存か
独立かは、それとは別の話だな。

NetBSDは options FFS_EI をつければ、どちらのエンディアンで書いた
ffs も読み書きできるし、MacOS X は、NetBSD から派生したコードも
含んでいるから、big endian で書かれたファイルシステムを、
little endianの Core Duo マシンで読み書きできても不思議はない。

MacOS X の話をしてるのに Sun のドキュメントを引用するのは的はずれ。
実際にどうなのかは知らんが。
0081732006/05/05(金) 16:07:20
DarwinのufsのばいとおーだーはFreeBSDと同じ。
xnu/bsd/ufs/ufs/ufs_byte_order.cが変換。
mount時のoptionで指定可能。MNT_REVEND。

続きはmac板のUNIXスレで。>>76の馬鹿も知りたければ来な。
0082MACオタ＞79 さん2006/05/05(金) 16:08:13
>>79
面倒なのでまとめると
・英文Webページの内容を誤読。　<- 私の書き込みに英文記事への引用わ無いす
・後藤氏の記事を誤読　<- 誤読かどうかわ当該スレッドを読んで貰うとして､元記事がそういう性質のモノ
・MPP云々<- 分類についてわTop500.orgサイトの記事を読んでDr. Dongarraに文句を言って欲しいす(笑)
0083MACオタ＞73 さん2006/05/05(金) 16:09:52
>>81
それってUFSでMS Officeが不具合を発生する原因なんすか(笑)
0084名無しさん＠お腹いっぱい。2006/05/05(金) 16:10:44
>>56
そこのベンチマーク、Createの結果はあっても他がないねー。
bonnie++がZFSでのReadとDeleteに対応してないとか？

NFS経由の結果はあるから、それを見る限りファイル操作は
ext3の半分ぐらいのパフォーマンスかな。
ただReadはむしろ早いから、ほとんどの用途では全体的に早くなりそう。
用途として向かないのはメールサーバぐらいかな？

あとZFS使ってる人いたら、暗号化した状態とかで、
ベンチマークしてみてもらえませんか？
http://www.coker.com.au/bonnie++/
0085名無しさん＠お腹いっぱい。2006/05/05(金) 16:14:13
Dr. Dongarra が、SR8000 を大規模SMPだなんて書いたことは一度も
ない筈だが、何言ってんだ、このバカは？
0086名無しさん＠お腹いっぱい。2006/05/05(金) 16:21:07
○関連スレ
/**ファイルシステム総合スレ その4**/
http://pc8.2ch.net/test/read.cgi/linux/1136695633/


○関連リンク
ファイルシステム比較
ttp://en.wikipedia.org/wiki/Comparison_of_file_systems

ベンチマーク
ttp://www.opensolaris.org/jive/thread.jspa?messageID=19368

分かりやすいZFSの解説
ttp://kikyou.info/diary/?200603#i10
0087名無しさん＠お腹いっぱい。2006/05/05(金) 16:33:04
マカは何処でもうざいな
0088MACオタ＞85 さん2006/05/05(金) 16:55:36
>>85
　　--------------------
　　SR8000 を大規模SMPだなんて書いたことは一度もない
　　--------------------
SR8000わ90年代後半に開発され､日立のニュースリリースによると98年12月に初号機納入という代物す。
http://www.hitachi.co.jp/Prod/comp/hpc/jpn/news_j.html
同時期に開発されているPOWER3のSMP機ってのわ､16-wayでこんな筐体す。
http://www.univ-lille1.fr/calcul-intensif/corinfo.htm

SR8000の9-way SMPが「大規模｣じゃ無いってのわ､当時の常識から見てちと違うんじゃないすか？
0089MACオタ＠補足2006/05/05(金) 16:58:46
>>88
それから､
　　------------------------
　　Dr. Dongarra が、SR8000 を大規模SMPだなんて書いたことは一度も
　　ない筈だが、
　　------------------------
少なくとも､Top500の解説にあるように"Shared Memory MIMD"をMPPに分類するというのわ認めたと
思っておくす。
　　　・MPPマシンはメモリ共有アーキテクチャだと主張。
で､これ間違いなんすか(笑)
0090名無しさん＠お腹いっぱい。2006/05/05(金) 17:01:20
GWだなぁ…
0091名無しさん＠お腹いっぱい。2006/05/05(金) 17:02:04
スレ違いだからほどほどに＞MACオタ

HFS+でbonnie++のベンチマークしてみたけど、遅い遅いｗ
RAIDも使ってないし、G5 1.6GHzだし、しょうがないかな。

PowerMac G5 1.6GHz, Memory 1GB, HDD WD3200JD, Mac OS X 10.4.6, HFS+
Version 1.03, Size 300M, files 16
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
26612 91 56964 33 54835 25 35490 92 477783 86 +++++ +++
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
3650 66 9645 90 3885 67 423 12 25087 80 191 7
0092名無しさん＠お腹いっぱい。2006/05/05(金) 17:03:10

　 ┏┳┳┓ 　 　 ハイ. 　 　　┏┳┳┓
┏┫┃┃┃池沼と遊ぶのは ┃┃┃┣┓
┃┃┃┃┣┓ 　ここまで　┏┫┃┃┃┃
┃　 　 　 ┃┃┏━━━┓┃┃　 　 　 ┃
┃　池沼 　 ┣┫ . ･∀･ ┣┫. STOP！┃
┗━━━━┛┗┳━┳┛┗━━━━┛
　 　 　 　 　 　 ┏┻┓┃
　 　 　 　 ┏━┛　 ┣┻┓
　 　 　 　 ┗━━━┫　 ┗━┓
.　　　　　　 　 　 　　┗━━━┛
0093名無しさん＠お腹いっぱい。2006/05/05(金) 17:17:20
>>92
スマン、もうちょい遊ばして。(w

> 少なくとも､Top500の解説にあるように"Shared Memory MIMD"をMPPに分類するというのわ認めたと思っておくす。

馬鹿だねえ。まだ、それが誤読だと気づいてないのか？
Top500 の解説には、「MIMD マシンの一種として shared memory MIMDがある」
とは書いてあるが、「MPP は shared memory MIMD である」とは一言も書いてない。

MACオタは、そう書いてあると誤読して、Top500 の記述を引用したが、
じつはその引用部分には「MPP は shared memory システムではない」という
意味のことが書いてある。(w
そのことは Intel スレでさんざん陰に指摘されているのに、相変わらず
理解できてないようだな。(w

> ・MPPマシンはメモリ共有アーキテクチャだと主張。
> で､これ間違いなんすか(笑) もちろん間違い。
まだ気づいてなかったのは、はっきり言って、ちょっと驚いたよ。

> SR8000の9-way SMPが「大規模」じゃ無いってのわ、当時の常識から見てちと
> 違うんじゃないすか？

ハァ？
その何年も前に、10倍以上の規模を持つOrigin 2000 があったわ。
1997年ぐらいには、Sun あたりでも、64プロセッサの Enterprise 1000 を
出してる。
書けば書くほど、馬鹿がバレるんだから、いいかげんに黙れば？
0094名無しさん＠お腹いっぱい。2006/05/05(金) 17:29:01
>>91
メモリ1GBのマシンで Size 300M ではベンチマークにならんのでは？
最低でもメモリの倍くらい、できれば10倍くらいのサイズにしないと。
0095MACオタ＞93 さん2006/05/05(金) 17:51:16
>>93
　　----------------------
　　じつはその引用部分には「MPP は shared memory システムではない」という
　　意味のことが書いてある。(w
　　----------------------
間違いす。以上(笑)　http://www.top500.org/orsc/2005/architecture.html#architecture
0096名無しさん＠お腹いっぱい。2006/05/05(金) 17:56:03
陰どころか陽に指摘されても、相変わらず自分の勘違いが認識できないのね。
というわけで、池沼とのお遊びは、これで終りにします。
0097MACオタ2006/05/05(金) 18:09:57
>>96の粘着さんわ退場してくれたみたいすけど､そんなに自信があるなら該当個所を対訳でもすれば
良いかと思うす。私がやっても良いすけど､ここでやっちゃ迷惑そうなんで止めておくす。。。
0098名無しさん＠お腹いっぱい。2006/05/05(金) 18:17:34
読んでみたが、そのページの分類だと、ccNUMA も MPP の一種だと
いう風にもとれるね。MACオタの勘違いはそこから発してるのか？

しかし、ccNUMA は MPP に含まないと考えるのが普通だと思うよ。
たとえば、以下の SGI のページでも、ccNUMA は MPP-like な
スケーラビリティを達成できるのが利点である (すなわち ccNUMA
は MPP ではない) と書いてある。
ttp://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Developer/books/LX_AppTune/sgi_html/ch01.html
2005年10月28日発行だから、十分新しい文書だが。

Top500 のそのページの記述は変だな。
0099名無しさん＠お腹いっぱい。2006/05/05(金) 18:20:14
> MACオタの勘違いはそこから発してるのか？

だからと言って、カートナーとかいう調査会社があると想像する
理由にはならんだろう。(w
0100名無しさん＠お腹いっぱい。2006/05/05(金) 18:26:02
>>94
上のベンチマークのページと引数合わせてみた。
大して結果は変わらないねー。

PowerMac G5 1.6GHz, Memory 1GB, HDD WD3200JD, Mac OS X 10.4.6, HFS+
bonnie++ -r 1024 -s 8g
Version 1.03, Size 8G, files 16
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
26800 92 53541 32 24789 12 27211 73 51446 15 118.0 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
4132 77 8548 91 3723 67 429 13 26851 87 194 7

Xserve G5 x 2 Fedora 5でも今試してるけど、
なぜか10倍ぐらい時間掛かってる。
結果が出たら報告する。
0101名無しさん＠お腹いっぱい。2006/05/05(金) 18:38:28
bonnie++の結果を検索してみたけど、
どれもディスク速度が遅くて比較にならない。

ttp://yamk.net/0930.html
ttp://t.nomoto.org/diary/archives/2005_01.html
ttp://lists.debian.org/debian-knoppix/2003/02/msg00285.html
ttp://www.ait.pref.akita.jp/~kurosawa/raidLogComp.html

一つ言えるのはHFS+とかXFSとかののBツリー型はDeleteが遅いってことかな。
0102名無しさん＠お腹いっぱい。2006/05/05(金) 19:31:42
Xserve G5 x 2, Memory 2GB, HDD 不明250GB, Fedora Core 5, ext3
bonnie++ -r 1024 -s 8g
Version 1.03, Size 8G, files 16
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
5051 99 42674 27 22711 9 5508 99 56594 8 135.5 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
15274 99 +++++ +++ 23921 99 14764 94 +++++ +++ 23868 99

ZFSの人、報告頼む。
0103632006/05/05(金) 19:39:33
Nevada snv_38 X86,64bit,AMD Athlon(tm) 64 Processor 3200+,ST380011A
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
machine 2G 21737 25 25737 7 17059 3 47881 57 49757 3 216.4 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 19664 68 +++++ +++ +++++ +++ 28324 97 +++++ +++ +++++ +++
machine,2G,21737,25,25737,7,17059,3,47881,57,49757,3,216.4,0,16,19664,68,+++++,+++,+++++,+++,28324,97,+++++,+++,+++++,+++


こんなんでいいのかな。
0104632006/05/05(金) 19:44:20
10Gで再度。

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
machine 10G 20091 23 25023 6 16578 3 40543 49 45665 3 200.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 27625 92 +++++ +++ +++++ +++ 15546 57 +++++ +++ 23038 54
machine,10G,20091,23,25023,6,16578,3,40543,49,45665,3,200.3,0,16,27625,92,+++++,+++,+++++,+++,15546,57,+++++,+++,23038,54
0105名無しさん＠お腹いっぱい。2006/05/05(金) 19:53:41
> 大して結果は変わらないねー。

sequential output の rewrite (54.8MB/s vs 24.8MB/s)
sequential input の block (478MB/s vs 51.4MB/s)
random seek (86/sec vs 15/sec)
あたりはかなり違いが出てると思うよ。
478MB/s って値は、メモリキャッシュのせいだね。
0106名無しさん＠お腹いっぱい。2006/05/05(金) 20:14:03
やってみますた。
nv_b37, Blade 1000 750MHz, LSI logic SAS1068, T7K250 x3 台
# zpool iostat -v (default の stripe)
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
mypool 288K 696G 2 3 336K 441K
c2t0d0 220K 232G 0 1 112K 147K
c2t1d0 28K 232G 0 1 112K 147K
c2t2d0 39.5K 232G 0 1 112K 147K
---------- ----- ----- ----- ----- ----- -----

# ptime mkfile 10g testfile_10g
real 1:46.628
user 0.196
sys 41.708

bonnie++:
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
machine 8G 25108 98 63450 61 53474 62 23554 97 135876 86 840.4 8
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 6405 99 +++++ +++ 10016 99 6580 97 +++++ +++ 11205 99
machine,8G,25108,98,63450,61,53474,62,23554,97,135876,86,840.4,8,16,6405,99,+++++,+++,10016,99,6580,97,+++++,+++,11205,99

0107名無しさん＠お腹いっぱい。2006/05/05(金) 20:16:09
>>103-104
ありがとー。
Createの速度は十分速いけど、なぜかReadとDeleteの結果がないね〜。
上のベンチマークのページにもないんだよねー。なんでだろ？

あと暗号化ってもう実装されてるのかなー？
Solaris 10 6/06のZFS 1.0で実装されてくるかな？
0108名無しさん＠お腹いっぱい。2006/05/05(金) 23:07:15
613 名前：login:Penguin [] ：2006/05/05(金) 18:42:17 ID:ixPDtLg1
今ZFSスレでFSベンチマークやってるんだけど、GWで暇な人、一緒にやらない？
http://pc8.2ch.net/test/read.cgi/unix/1146631270/

bonnie++
ttp://www.coker.com.au/bonnie++/

Linux板に張り付けてくんじゃねえよ、ロリBSD野郎共
0109名無しさん＠お腹いっぱい。2006/05/05(金) 23:18:06
以外にスレが伸びてるな


と書くとスレが止まる法則
0110名無しさん＠お腹いっぱい。2006/05/05(金) 23:24:01
>>106
構成で誰だか分かってしまうｗ
0111名無しさん＠お腹いっぱい。2006/05/05(金) 23:34:09
>>108
残念、貼り付けた犯人はLinux&Mac使いでした。

>>109
使ってる人が増えないと、スレも伸びなさそう。
Solarisってシェア大きいのかな？
0112名無しさん＠お腹いっぱい。2006/05/05(金) 23:42:12
>>110

(*´д｀*)

　ZFS on disk encryption support
　http://www.opensolaris.org/os/project/zfs-crypto/

　Source updated against onnv_39
　http://www.opensolaris.org/jive/thread.jspa?threadID=8587&tstart=0

--
I've put up the latest set of sources which are diffs against onnv_39.

http://opensolaris.org/os/project/zfs-crypto/files/diffs.onnv_39

Note that these still don't do any crypto yet, I'm debugging a problem
in the ZIO pipeline with zfs_write_encrypt not getting called when I
expect it should.
--
0113名無しさん＠お腹いっぱい。2006/05/06(土) 00:00:24
>>72
有名人が間違いを広めないでください。
UFSで多くのアプリで互換性に問題が発生するのは、Cabon File Manegerに、使用できない関数が大量にあるためです。
これらのAPIは、UFSの能力不足が原因で未実装になっています。
大文字小文字問題は、修正の容易な軽微な問題です。

>>75
ファイルシステムのエンディアンの問題と言うのは、エンディアンの異なるマシンの間でドライブを繋ぎ変えた時に発生します。
特定アプリの互換性云々では無いので、心配不要です。

MACオタさんは、本職がハード屋さんなんじゃないかと想像。
0114名無しさん＠お腹いっぱい。2006/05/06(土) 00:09:34
>>113
つうことは、仮にZFSを導入したとしても、同じことが起きるんちゃうん？
0115MACオタ＞113 さん2006/05/06(土) 00:59:18
>>113
　　---------------------
　　有名人が間違いを広めないでください。
　　UFSで多くのアプリで互換性に問題が発生するのは、Cabon File Manegerに、使用できない関数が
　　大量にあるためです。
　　---------------------
失礼したす。リソース関係だけかと思っていたすけど､File IDが使えないらしいのわMacintoshのソフトとして
わ大問題すね。
0116名無しさん＠お腹いっぱい。2006/05/06(土) 01:13:54
>>98
なにもよんでないけど
アーキテクチャの分類は
いろいろ直交したのがあるから。
SMPかつMPPなのはSUNがやっているようにweb serviceにフォーカスしてる。
ccNUMAのMPPはHPCより。

0117名無しさん＠お腹いっぱい。2006/05/06(土) 02:23:02
えー、HPCの世界では、MPPとccNUMAは完全に別物でしょう。
>>98 にある資料もそうだけど、
ttp://ece.uprm.edu/~wrivera/ICOM6025-2005/lecture2.pdf
とか
ttp://teamquest.se/resources/gunther/display/11/index.htm
とか
ttp://www.gfdl.noaa.gov/reference/AR00/1FMS.html
とか
ttp://liris.cnrs.fr/~jpierson/DEAGrids/DEAParallel.ppt
とか、ググってでてくる資料も、MPP は shared nothing な
distributed memory system だと書いてあるものばかり。
それって、いったいどこの世界のHPC？

ビジネス寄りの web service の世界では、そもそもMPPなんて
言葉は聞いたことないなあ。実際、使われてないしね。
でっかいのは大規模SMPばかりでしょ。

> ccNUMAのMPPはHPCより。

ビジネスで使われてる大規模SMPシステムは全てccNUMAだよ。
そんなことも知らんの？
0118名無しさん＠お腹いっぱい。2006/05/06(土) 02:25:10
ここはZFSの中核スレッドだな
0119MACオタ＞117 さん2006/05/06(土) 02:39:38
>>117
だ・か・らMPPってのわ90年代のHPC業界の流行語に過ぎないす。

そして､top500の編者達わ､"the buzz-word MPP systems is fashonable here"と断じて､
(http://top500.org/orsc/1996/node3.html 参照)より明確に
　・Shared-memory SIMD
　・Distributed-memory SIMD
　・Shared-memory MIMD
　・Distributed-memory MIMD
という分類を広めようとしてるんだと思うす。
0120名無しさん＠お腹いっぱい。2006/05/06(土) 02:50:20
> そして､top500の編者達わ､"the buzz-word MPP systems is fashonable here"と断じて､

この文章を google で検索 → 0件。
MACオタの脳内妄想ですな。

> (http://top500.org/orsc/1996/node3.html 参照)より明確に

それって、URLに1996年って入ってることから見ても分かるように、
90年代のHPC業界の資料なんだけど。(w

ちなみに、もちろん2000年代になってもMPPという言葉は使われてます。
たとえば、これは小柳先生が半年前に書いた資料。
ttp://olab.is.s.u-tokyo.ac.jp/~oyanagi/reports/SC2005.html
HPC 業界にいる人間なら全員読んでるよ。
MACオタは読んだことなかっただろうけどさ。
0121名無しさん＠お腹いっぱい。2006/05/06(土) 02:53:25
てゆうか、>>98 にある SGI の資料 (2005年10月28日発行) でも
MPP って使ってるじゃん。MACオタって、6時間前のレスも忘れち
まうのか？
0122名無しさん＠お腹いっぱい。2006/05/06(土) 02:55:52
> この文章を google で検索 → 0件。
> MACオタの脳内妄想ですな。

おっと、
http://www.ime.st/top500.org/orsc/1996/node3.html
自体に書かれていたのか。
文章が MACオタの脳内妄想だというのは撤回する。
失礼した。
0123名無しさん＠お腹いっぱい。2006/05/06(土) 03:02:53
それはそれとして、

> そして､top500の編者達わ…という分類を広めようとしてるんだと思うす。

この想像自体は、やっぱりMACオタの脳内妄想ですな。
だって、top500 自体、いまだに
ttp://www.top500.org/sublist/
といったページで、Computer Architecture の項目の分類として
MPP って言葉を使ってるしね。

>>119がMACオタの妄想じゃないとすると、ここは
当然
・Shared-memory SIMD
・Distributed-memory SIMD
・Shared-memory MIMD
・Distributed-memory MIMD
でないといけない筈だよな。(w
0124名無しさん＠お腹いっぱい。2006/05/06(土) 03:43:58
たまにはZFSの話もしようぜ。
01251172006/05/06(土) 04:00:14
すまん。ちょっと訂正だけさせて。

> ビジネスで使われてる大規模SMPシステムは全てccNUMAだよ。

IBM pSeries 690 とか Sun Fire 15K とか SGI Altix は ccNUMA だけど、
富士通の PRIMEPOWER はクロスバーを使ってて UMA らしい。
HP Superdome もそうみたい。
というわけで「全て」というのは間違いだった。ｽﾏﾝ。
01261172006/05/06(土) 04:17:31
と思ったら、HP SuperDome はセル内はクロスバーを通らなくて
速く、結局 ccNUMA だった。というわけで、大規模 SMP の中で
例外はPRIMEPOWER だけかも。
0127名無しさん＠お腹いっぱい。2006/05/06(土) 05:18:53
いいかげんスレ違いだから他でやってくれまいかね。
0128誘導2006/05/06(土) 06:21:12
ということで、この続きはこちらでやりましょう。
ttp://pc8.2ch.net/test/read.cgi/unix/1146631270/
0129名無しさん＠お腹いっぱい。2006/05/06(土) 09:07:37
自レスに誘導とは…。
どこのスレの誤爆だろう。
0130名無しさん＠お腹いっぱい。2006/05/06(土) 10:41:52
ネタだろ？
すべったけど。
0131名無しさん＠お腹いっぱい。2006/05/06(土) 10:59:02
>>114
Appleの中の人の優先度の高い検討事項でしょうね。
0132MACオタ＞131 さん2006/05/06(土) 13:43:10
>>131
むしろHFS+同様の豊富なmegadataサポートという仕様に目をつけてZFS採用を検討しているように見えるすけど。。。
0133名無しさん＠お腹いっぱい。2006/05/06(土) 14:29:54
聞いた話だと、HFS+って9からXに移行したときにジャーナル機能をつけたってことらしいんだけど
ZFSを検討してるって事は、Apple的にはファイルシステムとして自信がないってことなのかな？
ext3がext2にジャーナルつけてもヘタレなままなのと同しで、HFS+も弱いんでしょうか？

基本的にAppleがZFSをメインに据えて、HFS+を廃止ない限りZFSにはならないと思う
両立路線で行くと、みんなHFS+しか使わないから、ZFS上でMac OS Xで使う上で問題が出る気がする
UFSのときと同じで一過性のもので終わるんじゃないですかね？

ZFS使ってXの機能をブラッシュアップする斬新な計画があるならいいけど
そうでなければ、話題性に利用して終わると思うな。Appleっていつでもそうだし
0134名無しさん＠お腹いっぱい。2006/05/06(土) 14:33:40
>>129-130
残念、貼り付けた犯人はLinux&Mac使いでした。
0135名無しさん＠お腹いっぱい。2006/05/06(土) 15:16:20
>>133
プリインストールとデフォルト導入時のファイルシステムを ZFS にするだけの
ことだと思うけど。UFS はそうしてもらえなかっただけでしょ。
0136名無しさん＠お腹いっぱい。2006/05/06(土) 15:18:04
>>132
だよね。どっかの記事にそう書いてあったと思うけど。
MacOS でのセマンティクス実現するのが楽だとかなんとか。
metadata ねw。
0137誘導2006/05/06(土) 15:19:07
ということで、この続きはこちらでやりましょう。
ttp://pc8.2ch.net/test/read.cgi/unix/1146631270/
0138名無しさん＠お腹いっぱい。2006/05/06(土) 15:21:22
>>135
ZFSはデフォルトになるの？
0139名無しさん＠お腹いっぱい。2006/05/06(土) 15:43:00
痴漢冤罪詐欺師ベッキー(22)刑事告訴へ動き

痴漢は犯罪です。しかし、痴漢冤罪はそれ以上の犯罪です。
痴漢冤罪被害者は現在事実上社会復帰が不可能です。
痴漢冤罪加害者は人殺しと同罪です。
産廃未満は家事手伝いというニート職に甘んじていて下さい。

ν速＋　http://news19.2ch.net/test/read.cgi/newsplus/1146892373/
ソース　ttp://www.naispo.net/entertainment/20060504/01.php
0140名無しさん＠お腹いっぱい。2006/05/06(土) 16:37:08
>>138
カーネルを Solaris に置き換えてしまうための地ならしかも知れんぞ。
今、サーバー機どうするか悩んでるはずだし。Mach がんばって改良するより
Solaris ぽんと持ってきた方が早あがりだし安い。
0141名無しさん＠お腹いっぱい。2006/05/06(土) 17:30:15
Solarisのカーネル見てみんな自分のやってることが馬鹿らしくなったんだな
サーバーOSはもうSolarisしかありえん。その他のデスクトップや組み込みなら
いろいろ努力する甲斐もあるだろうけどさ。
0142名無しさん＠お腹いっぱい。2006/05/06(土) 18:35:41
>>140-141
Solarisのkernelってそんなにいいの？
LinuxやFreeBSDのkernelなら雑誌とかで読んで、少しは知ってるけど。

先生、Solarisのkernelについて教えてください。
0143名無しさん＠お腹いっぱい。2006/05/06(土) 19:05:26
>>142
ttp://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/main.c
275 行目からゴー。
0144名無しさん＠お腹いっぱい。2006/05/06(土) 19:07:40
>>141
もうちょっとウガッた見方すると、PowerPC でソデにされた IBM によっぽど
腹立てて、AIX への当てつけとかww
0145名無しさん＠お腹いっぱい。2006/05/06(土) 19:14:22
なぜファイルシステムのスレはどれもこれも知能が低いのだろう
0146名無しさん＠お腹いっぱい。2006/05/06(土) 19:19:03
>>145
へえ
0147MACオタ＞141 さん2006/05/06(土) 19:19:49
>>144
どっちかというとAppleに逃げられたために､貧乏オープンソースプログラマをこき使って､POWERへ
良質のオープンソースソフトを移植させて大儲け。。。って目論見が潰えてショックを受けてるのわ
IBMかと思うす。
■ このスレッドは過去ログ倉庫に格納されています