ZFSの最近のブログ記事

Leopard 用の新しい ZFS binary がリリースされました。
Nevada b72 相当とのこと。
source code も公開されています。

10.5.1 に upgrade すると、developer.apple.com で配布されている Beta Seed がインストールできない問題がありましたが、こちらでは直ってます。というか、手作業でインストールでし。

http://zfs.macosforge.org/?page_id=5

ZFS は、ファイルを格納する際、user data と、meta data と呼ばれる 2 つの data を filesystem に記録します。
user data は、ファイル本体となり、meta data は、そのファイルの block pointer 情報などを記録したものとなります。

この場合、どちらかが破壊されてしまうと、そのファイルを読み出すことはできなくなります。
そこで、ZFS version 2 で、ditto blocks と呼ばれる、meta data の複製を作成する機能が追加されました。
＃ちなみに、Nevada b62 では、ZFS version 6 になっています。
　Solaris 10 11/06 は、ZFS version 3 です。

これで、片方の meta data が壊れてしまっても、user data を読み出すことができるようになり、信頼性も向上しましたが、やはり、user data も複製できるほうがよくね？
という議論が交わされ、Nevada build 61 において、user data でも ditto blocks 機能が利用できるようになったようです。

default では、zfs set copies=1 が設定されており、user data の copy は作成しません。
これを、zfs set copies=2 とすることで、user data の複製が作成されるようになり、最大 3 つの user data のコピーを作成することが可能となります。
複数の meta data のコピーと、複数の user data のコピーが作成されるので、信頼性も一気に向上します。

ファイルシステムの中で、RAID を組んでいるという感じでしょうか。
ファイルレベルとハードウェア(ディスク)レベルで冗長性を確保できるのでつか。
が、当然、コピーを作成するので、複製を 2 つ作成する場合は、2 倍の容量が必要となってしまいますが、data protection という意味では、すばらしい機能かと思います。

また、user data の copy は、zfs set copies を設定した後に書き込まれたファイルに対し有効になるもので、それ以前のデータには適用されない点に注意。
これを解決するために、zfs rewrite オプションみたいなものを実装しようぜ的な意見もあるようです。

詳細については、以下の blog で。分かり易く、図解入りで書かれています。

http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection

リリースされますた。

zfs boot image patching kit とか、ZFS Boot manual instruction とか参考にして、れっつチャレンジ。
SPARC な人は、指を加えて見ていましょう。

http://www.opensolaris.org/os/downloads/

ちょっと前に、98% 完了との記事がでましたが、移植完了のアナウンスがでてました。
FreeBSD 7.0-current で、利用可能とのこと。
今日から君も、Lets, zpool create!
おつかれさまでした。

http://journal.mycom.co.jp/news/2007/04/06/017/index.html

http://en.wikipedia.org/wiki/Zfs#Current_implementation_issues

ZFS な filesystem の snapshot 取得を SMF で自動化させる方法。

http://blogs.sun.com/roller/page/timf?entry=zfs_automatic_snapshots_smf_service

ON nightly 20060508 を Nevada b37 に BFU してみる。
これが噂に聞く、zfs upgrade でつね。

zfs upgrade mypool でサクッと upgrade 完了。

 

ディスク 1 台で zfs を構成した場合、パフォーマンス的には、パッと見、あまり違いが見えないので、compression on/off での違いを見てみました。

compression on/off は、

    # zpool create -f mypool c2t0d0
    # zfs set compression=on (or off) mypool

で。default は、off です。
ちなみに、property を見るには、

    # zfs get all mypool

などで見れます。mypool の部分は、pool 名 or zfs volume になります。


mkfile で 1G のファイルを作成し、Nevada b37 で実装された fsstat と sar を使って4秒間隔で統計とってみました。
compression を on にすると、爆速になりますね・・・
まぁ、mkfile で使ったファイルが圧縮されるわけですから、それなりに小さくなるので速くなると・・・
こんな安易な方法で、比べる意味ねぇなと orz

わかったことと言えば、compression: on にすると、CPU 使用率が結構上がってしまうということでしょうか。

compresson: off

--
# ptime mkfile 1g 1g

real       20.561
user        0.019
sys         3.979


# fsstat /mypool 4  
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
   27    13     0   408    11    470    92    20 1.48K 1.20M 17.8G /mypool
    1     0     0     2     0      0     0     0     0 1.49K  191M /mypool
    0     0     0     0     0      0     0     0     0 1.49K  191M /mypool
    0     0     0     0     0      0     0     0     0 1.49K  191M /mypool
    0     0     0     0     0      0     0     0     0 1.49K  191M /mypool
    0     0     0     0     0      0     0     0     0 1.62K  207M /mypool
    0     0     0     0     1      1     0     0     0   431 53.9M /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool

# sar 4 6

SunOS empress-240 5.11 snv_37 sun4u    05/10/2006

18:59:59    %usr    %sys    %wio   %idle
19:00:03       0      20       0      80
19:00:07       0      21       0      79
19:00:11       0      22       0      78
19:00:15       0      21       0      78
19:00:19       0      30       0      70
19:00:23       0       8       0      92

Average        0      20       0      79

--

 compression: on

--

# ptime mkfile 1g 1g          

real        6.929
user        0.018
sys         3.234

# fsstat /mypool 4
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
   28    14     0   413    12    475    92    20 1.48K 1.20M 18.8G /mypool
    1     0     0     2     0      0     0     0     0 3.24K  414M /mypool
    0     0     0     0     1      1     0     0     0 4.76K  610M /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool
    0     0     0     0     0      0     0     0     0     0     0 /mypool

# sar 4 6

SunOS empress-240 5.11 snv_37 sun4u    05/10/2006

19:01:52    %usr    %sys    %wio   %idle
19:01:56       0      31       0      69
19:02:00       0      48       0      51
19:02:04       0       8       0      92 <- この時点の統計では、すでに書き込みが終わっている
19:02:08       0      11       0      89

--
 

わかりやすく説明されているかと思います。

zfs の compression property を使う説明があるけど、これってどうなんだろ。
b27 でリリースされたときは、compression が default: on になっていたみたいだけど、問題があったようで b29 で default: off になった。
compression: on にすると、確かに書き込む前に圧縮しているようで書き込み時間は短くなるけど・・・

http://www.sun.com/software/solaris/howtoguides/zfshowto.jsp

2ch に ZFS スレができてますた。
実家への帰省中、楽しませてもらいましたが、中には、環境で特定されている人もい(ry

storage pool から、適当な容量で切り出した volume を block device として扱える機能がありまつ。
これを使って、切り出した volulme に newfs かけて、その volume を UFS として利用してみるとどうなるかと思い実験してみますた。

すでに、構成されている storage pool: mypool から、 test という名前で 10GB の volume を切り出しまつ。
--
# zfs create -V 10g mypool/test
--

これで、/dev/zvol/{dsk,rdsk}/test という device ができあがり。
あとは、newfs /dev/zvol/rdsk/test して、UFS を構築。
mount -F ufs /dev/zvol/dsk/test /mnt なんてやってあげて、mkfile 1g とかしてみる。
いやー、あたりまえですけど、３倍くらい遅くなりますた。
まぁ、とりあえず block device にしてしまえば、Solaris が support している filesystem は、構築できるということがわかりました。
それだけでつ・・・