トップページ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/
0002名無しさん@お腹いっぱい。2006/05/03(水) 13:44:17
Mac板に建てようかと思ったけど、この板の方が詳しい人多そう。
というわけで、Solaris使いの人いろいろ教えてください。

参考
ttp://kikyou.info/diary/?200603#i10
0003名無しさん@お腹いっぱい。2006/05/03(水) 14:15:47
>>2 そのページにあがってるこれがわかりやすいね。すごいや。
ttp://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf
0004名無しさん@お腹いっぱい。2006/05/03(水) 14:47:09
コマンドのとこちょっと訳してみた。

プールとファイルシステムを作成

・「tank」という名前のミラー設定のプールを作成
# zpool create tank mirror c0t0d0 c1t0d0

・/export/home へマウントするホームディレクトリーファイルシステムを作成
# zfs create tank/home
# zfs set mountpoint=/export/home tank/home

・数名のユーザーのホームディレクトリーを作成
注: 継承機能のため自動的に /export/home/{ahrens,bonwick,billm} にマウントされる
# zfs create tank/home/ahrens
# zfs create tank/home/bonwick
# zfs create tank/home/billm

・プールに容量追加
# zpool add tank mirror c2t0d0 c3t0d0
0005名無しさん@お腹いっぱい。2006/05/03(水) 14:48:27
属性の設定

・全ホームディレクトリーを自動的に NFS エクスポート
# zfs set sharenfs=rw tank/home

・プール内の全てを圧縮設定
# zfs set compression=on tank

・Eric のクォータを 10g に制限
# zfs set quota=10g tank/home/eschrock

・Tabriz に 20g の予約を保証
# zfs set reservation=20g tank/home/tabriz

ZFS スナップショット

・Mark のホームディレクトリーのスナップショットを取る
# zfs snapshot tank/home/marks@tuesday

・以前のスナップショットにロールバックする
# zfs rollback tank/home/perrin@monday

・水曜日の版の foo.c をちょっと見る
$ cat ~maybee/.zfs/snapshot/wednsday/foo.c
0006名無しさん@お腹いっぱい。2006/05/03(水) 14:49:58
ZFS バックアップ/リストア

・フルバックアップ実施
# zfs backup tank/fs@A > /backup/A

・差分バックアップ
# zfs backup -i tank/fs@A tank/fs@B > /backup/B-A

・遠隔複製: 1 分間分の差分を送出
# zfs backup -i tank/fs@11:31 tank/fs@11:32 | ssh host zfs restore -d /tank/fs

ZFS データ移行

・旧サーバーのプールをエクスポート
old# zpool export tank

・新サーバーへ物理的にディスクを移動し、プールをインポート
new# zpool import tank
0007名無しさん@お腹いっぱい。2006/05/03(水) 15:49:15
能書きみてるとすごそうだが、パフォーマンスちゃんと出るんかこれ。
0008名無しさん@お腹いっぱい。2006/05/03(水) 15:56:39
FreeBSDとかLinuxとかにも移植されて、標準のファイルシステムになったらうれしいな。
0009名無しさん@お腹いっぱい。2006/05/03(水) 16:00:22
xfsみたいに異様にフォーマットに時間かかりそう…
0010名無しさん@お腹いっぱい。2006/05/03(水) 16:06:40
ZFS + zsh + カワサキ Z1 + ゼットン。これ最強。ロート Zi: は未使用にて不明。
0011名無しさん@お腹いっぱい。2006/05/03(水) 16:08:29
>>9
>>4 の通り、フォーマットという手順はないんじゃなかった?
0012名無しさん@お腹いっぱい。2006/05/03(水) 16:28:33
遅そうだけど、どうだろね。書き込みに対して毎回チェックサム計算するみたいだし。
遅ければ適材適所で。
速度、安定性ともども文句なければ迷わず載り換えだろうな。
0013名無しさん@お腹いっぱい。2006/05/03(水) 16:35:40
>>7,12 >>2 の記事引用。

> おおむね UFS より速いっぽいし、特定のデータアクセスパターンでは
> 4〜6倍速いらしいです。逆に特定のデータアクセスパターンではUFSに比べて
> 数倍遅いですが、改善する余地があるとのこと。

あと、>>2 の記事の

> I/Oパイプラインによる並列処理

あたり読むと、特に SMP では速そうな感じ。今後の多コアなサーバー用途には
向いてそう。
0014名無しさん@お腹いっぱい。2006/05/03(水) 16:39:55
>>13
いやつまりそれって「速い場合もあるし遅い場合もある」としか言ってないので
結局わかんねーじゃん。
0015名無しさん@お腹いっぱい。2006/05/03(水) 16:47:48
『おおむね UFS より速いっぽい』w
0016名無しさん@お腹いっぱい。2006/05/03(水) 17:01:36
UFSでさえモノにできてないMacが、ZFSを使いこなせるとは思えないけどな…

っつーか自分とこで開発しないで、目新しいそうな技術に注目して
「さすがはApple、目のつけ所がいいぜ」とか思わせようとする
乞食宣伝テクには、いつものことながら飽きれてしまう
0017名無しさん@お腹いっぱい。2006/05/03(水) 17:16:02
つか、UFSより現状のHFS+の方が高性能だと思いますが…
0018名無しさん@お腹いっぱい。2006/05/03(水) 17:23:37
>>16
私気がついただけで 2 ヵ所破綻してますが。
UFS 使いこなせてないなら、ZFS ポンと持ってきた方が楽やん。
よそから持ってくるより、自分とこで開発した方が「さすが Apple」に決まってるやん。
てことで、あんさんアホだっか? なんくせつけんなやボケ。
0019名無しさん@お腹いっぱい。2006/05/03(水) 17:54:14
>>16
UFSよりZFSの方がリソースフォークの扱いとかでMacで使うのに楽だと聞いたよ。
0020名無しさん@お腹いっぱい。2006/05/03(水) 18:58:09
いつのまにかベースがMach+FreeBSDじゃなくてOpenSolarisになってたら笑う。
0021名無しさん@お腹いっぱい。2006/05/03(水) 19:05:57
>>20
でも将来的にそういうのも考えてmicrokernelにしてんじゃないの?
solarisは無いと思うけど、freebsdやめるってのはありえない話ではないと思う。
0022名無しさん@お腹いっぱい。2006/05/03(水) 19:09:30
単純にBSDライセンスにあやかりたいからだろ?乞食なんだよ
0023名無しさん@お腹いっぱい。2006/05/03(水) 20:27:50
DragonFlyはZFSを移植する方向にあるようです:
ttp://leaf.dragonflybsd.org/mailarchive/kernel/2005-12/msg00040.html
0024名無しさん@お腹いっぱい。2006/05/03(水) 20:54:57
ZFSってオープンソースなの?BSDと同じライセンスで使えるのかな。
0025名無しさん@お腹いっぱい。2006/05/03(水) 21:16:26
↓のリンクでZFSのソース読んでみるとCDDLらしい
http://opensolaris.org/os/community/zfs/source/

ちなみにこっちがCDDLの日本語参考訳
http://opensource.jp/licenses/cddl1.html

BSDLと違って修正したソースコードは公開しなきゃならないけど
GPLみたいな感染性がないのがAppleにとって都合がいいんだろうね
0026名無しさん@お腹いっぱい。2006/05/03(水) 21:20:00
http://www.opensolaris.org/
http://www.opensolaris.org/os/licensing/
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/zfs/
0027名無しさん@お腹いっぱい。2006/05/03(水) 23:14:56
>>14
線形データアクセスの予測先読みをする機構があるから
通常のアクセスパターンだと速くなるみたいだよ。
0028名無しさん@お腹いっぱい。2006/05/03(水) 23:18:20
>>27
そういうのってzfs以外のファイルシステムでも実装できるんじゃないの?
0029名無しさん@お腹いっぱい。2006/05/03(水) 23:18:45
>>25
CDDLということは、Linuxにも移植できそうね。
ライセンス問題で採用しないディストリビューションもあるかもだけど。

ただLinuxにはZFSの機能の大半がすでにあるから、
Mac OS Xに移植するほどのメリットはなさそう。

実際にZFS使ってる人ってこの板にいるかな?
Solarisスレで声掛けたら捕まるかな?
0030名無しさん@お腹いっぱい。2006/05/03(水) 23:27:41
>>28
そりゃ実装できるかどうかで言えばFAT16にだってできるだろうけど
そんな指摘には意味なくない? ZFSではそういうある程度
インテリジェントな機構を最初からFSレベルに統合してるのが
キモなわけでしょ。ジャーナリングにしてもRAIDにしてもそうなわけで。
0031名無しさん@お腹いっぱい。2006/05/03(水) 23:40:19
>>29
あるにはあるけどな。
ファイルシステムの方は機能的には充実しているけど、実績がいまいちだし、
LVMやmdに至っては、どっちも本家筋に当たるHP-UXやSolarisの劣化コピーだしな。
そういう意味では、ZFSみたく一貫したものが欲しいところだな。
0032名無しさん@お腹いっぱい。2006/05/03(水) 23:42:45
http://en.wikipedia.org/wiki/Comparison_of_file_systems

LinuxにはReiser4があるからそれでいんでないの。
0033名無しさん@お腹いっぱい。2006/05/03(水) 23:46:59
reiser4も問題があるというのはあっちのファイルシステムスレで出てる
0034名無しさん@お腹いっぱい。2006/05/04(木) 02:34:19
ZFSが一つ心配なことが。
大きいファイルで一部だけを書き換える場合、
ZFSは別のブロックに一部データを書き込んでから、
ファイルシステムのツリーを変更するみたいだけど、
そんなことしてたら大きいファイルの場合、
ブロックがあちこちに点在(断片化)するんじゃないだろうか。

HFS+みたいに断片化してたら、
自動的に連続ブロックに移動させる機能でもあるのかな。
0035名無しさん@お腹いっぱい。2006/05/04(木) 03:12:55
>>34
ワラ
君は…ちょっと知識が足りないかも…
0036名無しさん@お腹いっぱい。2006/05/04(木) 03:16:00
>>34
CoW
0037名無しさん@お腹いっぱい。2006/05/04(木) 03:34:03
プールってLVMとどこか違うの?
LVM+JFS2の方がよくね?
0038名無しさん@お腹いっぱい。2006/05/04(木) 03:51:18
質問です。
>トランザクション的操作
>ディスク上のデータは必ず常に整合状態。fsck(1M)不要は当たり前、でjournaling filesystemではない
これって矛盾しているような気がするんですけれど・・・
トランザクション的操作=journaling
なんじゃないんですか?
0039名無しさん@お腹いっぱい。2006/05/04(木) 03:51:33
>>35
うーん、そうなのかなー。
詳しく教えてくださ〜い。
0040名無しさん@お腹いっぱい。2006/05/04(木) 03:58:40
トランザクション的操作というのは、
下の引用の一番頭のポインタを書き換えるまでは、
ファイルツリーに一切変更がないから、
いつでも元に戻せる(ロールバック)できるような様を表してるんじゃないかと。

他のFSのジャーナリングは、変更ログをどんどん書き足していって、
フラッシュ時にツリーに変更ログを書き込むことで、
フラッシュ前にOSが落ちたりしても復旧できる仕組みなんじゃなかったっけ?

> 整合性の保持には「何か書き込みを行う場合は必ず元データを新しい場所にコピーしてから」
> (copy-on-write)で、1つ版のあがったファイルシステムのイメージを作成し、
> 古い版を指している一番頭のポインタを新しい版を指すように変更する
> (ここがアトミック)という方法を行っているようです
0041名無しさん@お腹いっぱい。2006/05/04(木) 08:21:23
>>38
「的」ってのがアヤシイけど、
「トランザクション処理」ってのは、
複数の処理を一つのように処理すること。trans-action=処理をまたがって
FOLDOCだと See {atomic}と注釈。

Journalingはそれを実現するための技法。
更新記録を取りながら、更新を進めていく。
0042名無しさん@お腹いっぱい。2006/05/04(木) 14:52:30
まあ、もうすぐ製品版の Solaris にものるから、使われるようになったらすぐわかるよ。
だけどさ、特定のデバイスドライバとかと違って汎用のファイルシステムで、
しかも UFS に代えてこれから主流として使おうってもんなんだから、
一応 Fire E25K とかのハイエンドで業務利用するのも視野に入ったレベルで
実装がすすめられてるわけで、とりあえず入れてみました、この先実用まで
たどりつけるかどうかわかりません、てないい加減なもんでは少なくともないわな。
Linux のガラクタファイルシステム群といっしょくたにすんなよな。
0043名無しさん@お腹いっぱい。2006/05/04(木) 15:19:35
NetBackupなどのバックアップソフトも対応するまでにかなり時間がかかるだろうし。
本格的に普及するのは、あとバージョン二つぐらい上がらんとだめだろうな。
それまでSunが残ってるかどうか心配だがw
0044名無しさん@お腹いっぱい。2006/05/04(木) 15:28:25
UFS使わなくなるとufsdumpの名前なりポジションが気になるな。

もちろんzfs snapshotなりなんなりでいいんだけど
0045名無しさん@お腹いっぱい。2006/05/04(木) 15:31:00
ufsdump は UFS 用なんだから、UFS 使わなくなったらポジションはないだろ。
UFS なくなったりはしないと思うが。
0046名無しさん@お腹いっぱい。2006/05/04(木) 15:38:41
ufsdump どころか、mount も vfstab も不要なんだろ?
0047名無しさん@お腹いっぱい。2006/05/04(木) 15:43:00
VxFSに対するダンプコマンドもufsdumpだよ。
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かwww
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
違うよ。
コテで無知晒すのって恥ずかしくない?
■ このスレッドは過去ログ倉庫に格納されています