トップページ⇒unix
983コメント275KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2007/06/13(水) 15:28:31
64ビットのチェックサム、128bitアドレッシング、RAID、ホットスペア、
スナップショット、ストレージプールなどの豊富な機能を備え、
次世代のファイルシステムとして期待されるZFSについて語るスレです。

○前スレ
[次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ]
http://pc11.2ch.net/test/read.cgi/unix/1146631270/

○関連スレ
/**ファイルシステム総合スレ その7**/
http://pc11.2ch.net/test/read.cgi/linux/1173530292/

○関連リンク
Solaris ZFS
ttp://www.sun.com/software/solaris/zfs.jsp

OpenSolaris
ttp://www.opensolaris.org/os/

ソース
ttp://opensolaris.org/os/community/zfs/source/
0662名無しさん＠お腹いっぱい。2008/04/16(水) 14:39:06
BeleniX すげーじゃん。ZFS ルートで導入できるらしい。
0663名無しさん＠お腹いっぱい。2008/04/16(水) 15:00:14
>>660
> 公開されてる仕様だけで普通に作ろうという話なのでは？

ちゃんと動きません。特に認証。
0664名無しさん＠お腹いっぱい。2008/04/16(水) 15:13:25
>>663
Solaris同士でマウントできればよくて、Windowsとのことは知らね、とかw
0665名無しさん＠お腹いっぱい。2008/04/16(水) 15:34:48
Closedなら簡単。
非公開の部分は独自仕様にすればいいから。
0666名無しさん＠お腹いっぱい。2008/04/16(水) 20:59:36
Solaris CIFSサービス遅いよ
0667名無しさん＠お腹いっぱい。2008/04/17(木) 07:02:00
最近MSがCIFSの仕様をSambaに提供するとかなんとか言ってたよね
0668名無しさん＠お腹いっぱい。2008/04/17(木) 08:33:23
EU対策の単なる方便でしょ。
0669名無しさん＠お腹いっぱい。2008/04/17(木) 10:25:29
出てるよ。「読む気しない」という反応だけはどっかで見たww
あまりに複雑だと公開しても一緒だという格言誰か作ってくれwww
0670名無しさん＠お腹いっぱい。2008/04/17(木) 11:35:44
あまりに複雑過ぎる問題はいくら目の数があっても解決できない
0671名無しさん＠お腹いっぱい。2008/04/17(木) 13:35:55
失敗した設計を文書であがなおうとすると、膨大な量に膨れあがった挙句、結局失敗する
0672名無しさん＠お腹いっぱい。2008/04/17(木) 14:08:50
長文是糞
0673名無しさん＠お腹いっぱい。2008/04/17(木) 22:43:27
zshが最強のシェルであるように
zfsも最強のファイルシステムなんだよな？
0674名無しさん＠お腹いっぱい。2008/04/17(木) 22:51:35
そりゃそうだろ。zshの最強度くらいzfsは最強さ。

ところで、俺はbafsが欲しいんだが。
0675名無しさん＠お腹いっぱい。2008/04/17(木) 22:57:31
aafsでいいや
0676名無しさん＠お腹いっぱい。2008/04/17(木) 23:13:06
tcfs
0677名無しさん＠お腹いっぱい。2008/04/17(木) 23:23:56
なにそのヴァカFS…
0678名無しさん＠お腹いっぱい。2008/04/18(金) 21:05:56
bafsって、ext2でいいんじゃね？
0679名無しさん＠お腹いっぱい。2008/04/18(金) 21:08:18
誰かZFSをWindowsに移植してくれー
0680名無しさん＠お腹いっぱい。2008/04/18(金) 23:00:16
Vistaじゃ100%使えんから却下。
0681名無しさん＠お腹いっぱい。2008/04/18(金) 23:41:01
iSCSIでマウント汁
0682名無しさん＠お腹いっぱい。2008/04/19(土) 22:05:28
FreeBSD 7-stable の zfs に結構更新が入ったみたい…

別スレでは不安定説が出ていますが
0683名無しさん＠お腹いっぱい。2008/04/21(月) 15:29:26
一時的に大きな更新が入ったからね。
ただ直ぐに改善するよ。
0684名無しさん＠お腹いっぱい。2008/04/21(月) 19:47:40
>>682
もしかしてThe great CDDL file moveのことを言っているのなら
それはファイルが移動しただけ。

>>683
ZFSのコードは年末からほとんど触れられていない。
大きな更新はないし改善もしない。
RELENG_7ではcacheのデフォルトを減らすのとzil_commit()をまめにするようになっただけ。
それも3ヶ月前の話。

もしそれ以上のことを知っているのなら教えて欲しい。
0685名無しさん＠お腹いっぱい。2008/04/23(水) 04:40:09
FreeBSD で ZFS を iSCSI Target にしたいんだけど無理？
0686名無しさん＠お腹いっぱい。2008/04/23(水) 07:39:31
無理ではないが無謀
0687名無しさん＠お腹いっぱい。2008/04/23(水) 12:23:06
ただ頑張れ、と応援したい。
0688名無しさん＠お腹いっぱい。2008/04/23(水) 13:47:24
オレが iZFS 開発するからもう少し待て。
0689名無しさん＠お腹いっぱい。2008/04/23(水) 21:27:55
じゃあ待つ
0690名無しさん＠お腹いっぱい。2008/04/25(金) 20:22:30
http://wiki.freebsd.org/ZFSTuningGuide

メモリ1GBも何に使ってるんだ?
0691名無しさん＠お腹いっぱい。2008/04/25(金) 21:29:45
まあ1Gぐらいならいいか…という気分になっていることは確か
0692名無しさん＠お腹いっぱい。2008/04/26(土) 00:28:17
サーバ機の1GBはそれほど安くない。
マックス1GBというわけでもないようだし、
メモリ不足でpanicする危険があるようでは
どんなに便利でも使えないではないか。
なぜ使えるメモリの範囲内でやりくりせんのだ。
0693名無しさん＠お腹いっぱい。2008/04/26(土) 09:36:16
このレベルやってる人間がそんなことわからんわけないだろw
0694名無しさん＠お腹いっぱい。2008/04/26(土) 10:17:23
ZFS使うSolarisにそんな要件はないので、
FreeBSDの実装はまだVMとのインタラクションが不十分なのではなかろうか。
0695名無しさん＠お腹いっぱい。2008/04/26(土) 19:07:58
>>694
32bit CPUでsolarisを動かすと発生する。
これに対するsunの対応は「x64使え」なので、
32bit CPUでzfsを使うなら
FreeBSD独自になんとかしなければならない。
0696名無しさん＠お腹いっぱい。2008/04/26(土) 23:52:24
fsが管理するメモリなんてcacheが大半だから
足りなくなってもpanicする前にいくらでも逃げようがあるだろう。

と思う俺は素人?

64bit archとメモリ1GBが必要だというなら用意すればいいが、
過負荷時の生存性の低さも潜在してるように思うぞ。
0697名無しさん＠お腹いっぱい。2008/04/27(日) 00:05:53
http://kerneltrap.org/FreeBSD/ZFS_Stability
> "I guess what makes me mad about ZFS is that it's all-or-nothing;
> either it works, or it crashes. It doesn't automatically recognize
> limits and make adjustments or sacrifices when it reaches those
> limits, it just crashes.
0698名無しさん＠お腹いっぱい。2008/04/27(日) 02:59:25
>>696
うん素人。オレも素人だけどそれだけは自信あるww
0699名無しさん＠お腹いっぱい。2008/05/01(木) 21:54:26
ReiserFSで有名な米国人プログラマー、殺人罪で有罪の評決
http://www.technobahn.com/news/2008/200804301057.html

Reiser のスレないみたいだからここに投下しとくか…
0700名無しさん＠お腹いっぱい。2008/05/01(木) 21:57:17
ここにはdump/restoreもないfile systemに興味のある人は皆無ですので、
Linux板あたりへどうぞ。
0701名無しさん＠お腹いっぱい。2008/05/02(金) 01:01:17
そうそう、あちらさんのファイルシステムって、dump/restoreがないのが
普通ってのがびっくりするよね。
まあpaxとかrsyncががんばってくれればいいと言われれば、ああそうですかって感じだけど。

0702名無しさん＠お腹いっぱい。2008/05/02(金) 02:03:41
普通って、reiserだけじゃないの？
0703名無しさん＠お腹いっぱい。2008/05/02(金) 02:06:00
しかし、ZFSの対象としている大容量なファイルシステムで、dump/restoreを使うか？
というジレンマもあるがな。
0704名無しさん＠お腹いっぱい。2008/05/02(金) 10:12:15
HDDの容量が増えたのなら
HDDにdumpすればいいじゃない
0705名無しさん＠お腹いっぱい。2008/05/02(金) 12:03:14
JFSもext2もdumpなかったような
0706名無しさん＠お腹いっぱい。2008/05/02(金) 12:54:29
snapshotがないFSでdumpは不整合の元だしな
0707名無しさん＠お腹いっぱい。2008/05/02(金) 12:56:12
>>704
あほか。容量の問題じゃなくて所要時間の問題なんだよ。
0708名無しさん＠お腹いっぱい。2008/05/02(金) 13:29:16
所要時間が長いのは前提で
その環境で如何に完全なバックアップを成立させるかってことじゃないの?

ZFS は send/receive がその役を担ってるんだよね?
0709名無しさん＠お腹いっぱい。2008/05/02(金) 14:10:18
うむ。snapshotあるんだからbackup windowは0だ。
オンラインではbackupする余裕がないのなら、それは資源の問題だ。
0710名無しさん＠お腹いっぱい。2008/05/02(金) 14:16:55
そうだよ。
別にLinuxの擁護するつもりはないけど、
dumpって絶対必要なのか？って訊かれれば、No、てことになるわな。
0711名無しさん＠お腹いっぱい。2008/05/02(金) 14:26:06
>>707
いやいや。メディア単価の問題でしょ? 世代管理と物理的に別箇所での保管。
0712名無しさん＠お腹いっぱい。2008/05/02(金) 14:56:21
>>711
何の話をしているんだ？それがdumpそのものと関係あるか？
0713名無しさん＠お腹いっぱい。2008/05/02(金) 15:42:12
tarだのcpioだのpaxだのrsyncだので
バックアップをとった *つもり* になるのは
よくないことだとおもいます。
0714名無しさん＠お腹いっぱい。2008/05/02(金) 15:51:27
お前は何を言っているんだ
0715名無しさん＠お腹いっぱい。2008/05/02(金) 16:04:45
>>705
LinuxのJFSってdumpできないの？

AIXってmksysbとかbackupとかあったと思うけど
あれはいわゆるdumpとは性格が違うんだっけ？

0716名無しさん＠お腹いっぱい。2008/05/02(金) 16:08:38
>>715
それってオンラインでバックアップとれるんでしょ？
つうことは、dumpとは違うんじゃね？
同じようなHP-UXのIgniteもバックアップ部分に関してはtarだし。
0717名無しさん＠お腹いっぱい。2008/05/02(金) 16:19:21
tarとかその他って、ハードリンクがちゃんと復元できるかどうか、とても不安にならない？
今どきハードリンクなんて使わねえよなんていう人は氏んでください。
0718名無しさん＠お腹いっぱい。2008/05/02(金) 16:55:37
お前は何を言っているんだ
0719名無しさん＠お腹いっぱい。2008/05/02(金) 17:16:50
>>717
話飛びまくりだなwwwww
cp -r で不安だから tar 使う、とか昔は言ったもんだ遠い目。
それを言うならホールだろ。
0720名無しさん＠お腹いっぱい。2008/05/02(金) 17:19:53
tarじゃあリンク復元完全にいかないことあるんだけど、知らない？
0721名無しさん＠お腹いっぱい。2008/05/02(金) 17:20:28
どの tar?
0722名無しさん＠お腹いっぱい。2008/05/02(金) 17:36:54
聞いたことないな。
むしろ心配すべきはシンボリックリンクのほうかとｗ
これも変なオプション付けなきゃ（デフォルトのままで）問題ないし。
0723名無しさん＠お腹いっぱい。2008/05/02(金) 17:59:10
「tarで問題ない」というのは
「僕はtarで問題に遭遇するほど場数は踏んでません」という意味だから、
永遠に話は噛み合わないと思うな。

tarも最近の実装なら問題ないと思うよ。検証してないしする気もないけど。
でもdump(zfs send)が使える状況なら、正確さと速度の両面でdumpが勝るのだから、
tarを使う理由はないだろう。
0724名無しさん＠お腹いっぱい。2008/05/02(金) 18:10:28
dumpとzfs sendじゃ仕組みが全然違うだろ。
一緒にするなよｗ
0725名無しさん＠お腹いっぱい。2008/05/02(金) 19:14:37
SunOS 4 付属の tar と GNU tar のこと知ってるやつならそう書くだろし。
かじっただけのマタ聞きに認定します今日は終了--
0726名無しさん＠お腹いっぱい。2008/05/02(金) 19:22:43
そういや 386BSD の配布は cpio だった。...って脱線しすぎだなww
0727名無しさん＠お腹いっぱい。2008/05/02(金) 22:54:50
solaris10でzfsのパフォーマンスをあげたいんだけど
どこかいじれるばしょってありますか?
0728名無しさん＠お腹いっぱい。2008/05/03(土) 01:01:00
メモリ増設
0729名無しさん＠お腹いっぱい。2008/05/03(土) 01:47:07
plan9はhard linkなしだったな。
On the fly snapshotの実装が複雑になるから。
0730名無しさん＠お腹いっぱい。2008/05/03(土) 02:14:56
>>726
386BSDじゃなくってもcpioってふつうによく使うじゃん。
0731名無しさん＠お腹いっぱい。2008/05/03(土) 11:56:48
「cpio 良く使う」で出身文化圏がわかる… のは言い過ぎか
0732名無しさん＠お腹いっぱい。2008/05/03(土) 16:15:51
ほぼ確実に読めるって事でcpioフォーマットを使ってる事は結構あるん
じゃないのかな。

商用バックアップソリューションのNetVaultもcpioフォーマットって
書いてあったと思うし。
安心感はあるかもね。

0733名無しさん＠お腹いっぱい。2008/05/03(土) 19:06:01
cpioを毛嫌いすることもないよ
0734名無しさん＠お腹いっぱい。2008/05/03(土) 20:35:47
cpioが嫌われる原因は、tarほど他OSとの互換性が高くないことその一点だろうな。
システムのバックアップとかに使うなら、tarより適している。
0735名無しさん＠お腹いっぱい。2008/05/03(土) 21:56:33
cpioはoption名が覚えにくい。
Solarisのパッケージはcpio使ってたな。
0736名無しさん＠お腹いっぱい。2008/05/03(土) 23:38:31
>>727
今どういう問題があって、どのような環境で、どういう風にパフォーマンスアップしたいのかしら？
0737名無しさん＠お腹いっぱい。2008/05/04(日) 00:13:59
cpio は互換性高いだろ。オプションが覚えにくいのと SysV 方面というイメージが敬遠要因と思うけど。
ま、昔の話だな。
0738名無しさん＠お腹いっぱい。2008/05/04(日) 19:36:33
ところで
disk fullになったときにrmでファイルを消せなくなる（かもしれない）というのはFAQですが
そのときの対処方法は？


0739名無しさん＠お腹いっぱい。2008/05/05(月) 00:48:48
知らないなあ…
0740名無しさん＠お腹いっぱい。2008/05/05(月) 18:06:27
各自が注意してdisk fullにしなければいいだけの話だろう。
あたかもFSの欠陥みたいに大騒ぎしてる奴は一体何が目的なんだ。
0741名無しさん＠お腹いっぱい。2008/05/05(月) 18:12:52
なんだそれ
0742名無しさん＠お腹いっぱい。2008/05/05(月) 18:16:21
disk fullに注意するのはいいが、なった時にファイルを消さないのは不具合でないの？
0743名無しさん＠お腹いっぱい。2008/05/05(月) 19:09:57
>>738
truncate
07447432008/05/05(月) 19:35:48
発掘した
ttp://lists.freebsd.org/pipermail/freebsd-current/2008-January/082615.html
0745名無しさん＠お腹いっぱい。2008/05/06(火) 10:48:33
クライアントのIPを指定してsharenfsってどうしたらいいのでしょうか?
0746名無しさん＠お腹いっぱい。2008/05/06(火) 18:29:55
ZFSと言うより、shareコマンドのオプションの問題。
0747名無しさん＠お腹いっぱい。2008/05/07(水) 01:20:30
>>745
ホスト名にする
or
/255.255.255.255 をつける
0748名無しさん＠お腹いっぱい。2008/05/07(水) 20:51:53
ZFS上でMySQL使ってる人っていないかな？

FreeBSD 7.0-RELEASE
MySQL 5.0.51a

で、試してるんだけど、INSERTが
ufs2の上に置いたときと比べて、8倍くらい遅いんだ。

recordsizeは、16kにしてみてる(´･ω･`)
0749名無しさん＠お腹いっぱい。2008/05/07(水) 23:28:19
大切な情報を忘れていました。
ディスク3本をraidzで組んでいます。
これから、raidzせずに変わるか試してみるよ！
0750名無しさん＠お腹いっぱい。2008/05/08(木) 00:22:01
RAIDの原理的に考えれば、
RDBから書き込むブロックサイズをRAIDのトータルブロックサイズ
にあわせないと、書き込みの度に読み出しが必要になって
遅くなるわな。
ディスク安いんだからRAID1がいいんじゃね。
0751名無しさん＠お腹いっぱい。2008/05/08(木) 00:46:50
RAID（のレイヤ）にブロックなんてあるの？
0752名無しさん＠お腹いっぱい。2008/05/08(木) 02:37:55
>>746
すみません、shareコマンドの無いFreeBSDユーザは /etc/exports
の形式をそのまま指定すれば良かったみたいです。

zfs set sharenfs='-maproot=root 192.168.0.1 192.168.0.10' tank/src
0753名無しさん＠お腹いっぱい。2008/05/08(木) 14:35:10
http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases
結論から言えば、database用途にはzfsは向かない。中でもRAID-Zは相性最悪。
0754名無しさん＠お腹いっぱい。2008/05/08(木) 16:00:27
容量拡張的には魅力あるんじゃない? 速度的にはともかくとしても。
ヘマしたら悲惨だとは思うがw
0755名無しさん＠お腹いっぱい。2008/05/08(木) 16:29:24
まあ、RAWつかえってことだわな。
0756名無しさん＠お腹いっぱい。2008/05/08(木) 16:49:31
追記型のPostgreSQLなら、zfsによるパフォーマンスの劣化は少ないかもね。
常にパフォーマンス優先というシチュエーションだけでもないので、
zfsが許容されるなら、recordsizeだけ気をつければいいのかも。
0757名無しさん＠お腹いっぱい。2008/05/08(木) 17:16:35
>>753
やっぱそうかw
まさしくRAID-Zで組んで何か遅いと思ったw
開発用DBの一つだから試験的に、と思ってたけどマシン性能に比べて遅いよなぁと思ってた・・・
0758名無しさん＠お腹いっぱい。2008/05/08(木) 17:44:57
>>753
DBの上にDB乗っけるようなものだからかなぁ
0759名無しさん＠お腹いっぱい。2008/05/08(木) 23:56:54
RDBMS用途では、ファイルシステム云々より、write cacheの有無が
性能を左右するんじゃないかな。
と言う事で、そこそこのwrite cache積んでいるハードウェアRAID上に
ZFS組めば、使えるのでは？
0760名無しさん＠お腹いっぱい。2008/05/09(金) 03:03:23
Oracleってzfsの上のソリューション紹介ってやってた記憶があるけど
おすすめってわけじゃないのかなぁ
0761名無しさん＠お腹いっぱい。2008/05/09(金) 09:05:35
>>759
正味 write back なとこに DB 置くの? チャレンジャーだな。
■ このスレッドは過去ログ倉庫に格納されています