Date: 2010/05/14 | | Tags: OpenSolaris, zfs, dedup
ZFSにはdedupと言われる機能があります。
名前から推察出来るとは思いますが、案外、ぴんと来ない人が多かったので簡単に説明しますと、ディスクの中に既に同じ内容が書き込まれていたら再利用するというものです。
つまり、シンプルに言うと、
とあったとき、保存されるのは、下記の5個
となり、データの節約が出来るという物です。実際は、ブロック単位(もしかするとzfs get recordsize?)なんですが・・・
またzfsには、cloneという機能によって、1つのファイルシステムのsnapショットから別のファイルシステムを作ることが出来ます。この場合、共通だった部分はそのまま利用し、以後、差分だけが保存されるため、再利用が可能です。
ただその後、オリジンとクローンに対して変更を個別に加えると、徐々に差分が増えます。仮に、同じようなことをしていたとしても、通常はバラバラになってしまいますよね。dedupをつかえば、ブロック単位で同じなら再利用されるため、ディスク容量とディスクアクセスを減らすことができます。
なんだか、とんでもないテクノロジのようですが、zfsの基準となっている、Copy On Writeで考えれてみれば、ファイル書き込みの時に既に同じシグネチャを持ったブロックがあれば再利用するように作れば上手くいくことがわかります。
つまり、snapshot/clone/dedupは仲間というわけです。
というわけで実験。
私のノートパソコンです。
zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 465G 291G 174G 62% 1.17x ONLINE -
dedup率が結構高いのは、zoneを多量に飼ってるいるからかな〜とか思いますが・・・・。それぞれにシステムのクローンがあるわけですしね。
ここで、先日作ったばかりのSourceJuicerの開発環境のovf(VirtualBoxやVMwareのイメージファイル)をコピーします。
ls -l SourceJuicr.7z
-rw------- 1 kohju justplayer 4324776131 3月 16日 13:30 SourceJuicr.7z
4.1Gもあるファイルです。
コピーします。すぐには終わりませんけどね。
cp SourceJuicr.7z tmp/
結果を見ます。
zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 465G 291G 174G 62% 1.21x ONLINE -
dedup率があがり、FREEは174GBのままです
更にコピーします。
せっかくだから時間計測・・・
time cp SourceJuicr.7z tmp/SourceJuicry.7z
cp SourceJuicr.7z tmp/SourceJuicry.7z 0.00s user 15.81s system 6% cpu 4:01.76 total
計算すると、17MB/secですね。通常ノートパソコンでコピーするとせいぜい5MB/secぐらいなので、速いのかな〜と思いますが、このパソコン、L2ARCとZILがあるので参考にはなりませんか(笑
コピー中の様子です。
kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr cd s0 -- -- in sy cs us sy id 10 0 0 131788 547932 0 896 0 0 0 0 0 37 504 0 0 2104 10243 1866 5 60 35 3 0 0 319424 657080 0 1550 0 0 0 0 0 75 414 0 0 16094 16839 2219 6 45 48 4 0 0 454512 690736 0 1264 0 0 0 0 0 26 431 0 0 24650 9957 2016 5 47 48 1 0 0 354820 575360 17 858 0 0 0 0 0 4 341 0 0 1788 19389 1978 7 33 60 5 0 0 584104 829384 0 966 0 0 0 0 0 6 376 0 0 36202 18169 2098 7 40 52 0 0 0 567512 957528 0 461 0 0 0 0 0 2 253 0 0 1685 24462 2201 11 25 64 0 0 0 526184 1125000 0 73 0 0 0 0 0 5 130 0 0 1354 24751 1950 12 14 74 0 0 0 524772 1295572 0 0 0 0 0 0 0 2 144 0 0 1359 16075 1605 7 15 78 2 0 0 523372 1382840 0 0 0 0 0 0 0 1 134 0 0 1349 23522 1848 11 16 72 0 0 0 522128 1439116 18 112 0 0 0 0 0 2 136 0 0 1520 35257 2259 16 16 68 0 0 0 520812 1513732 0 81 0 0 0 0 0 2 131 0 0 1371 22990 1907 11 14 75 2 0 0 518576 1532200 2 84 0 0 0 0 0 7 146 0 0 1580 32081 2395 16 20 64 0 0 0 516876 1531040 0 1 0 0 0 0 0 2 163 0 0 1482 30758 2193 13 20 67 0 0 0 510560 1524724 8 84 0 0 0 0 0 6 232 0 0 1560 25213 2190 12 21 67 0 0 0 495908 1425108 0 1050 0 0 0 0 0 25 379 0 0 2257 25142 2703 12 33 54 0 0 0 430008 1333344 22 879 0 0 0 0 0 0 397 0 0 2124 17693 1916 7 34 59 0 0 0 334132 1225560 0 209 0 0 0 0 0 1 315 0 0 1845 10929 1826 2 30 68 0 0 0 318348 1259676 0 177 0 0 0 0 0 1 190 0 0 1452 96711 2707 21 26 53 0 0 0 318344 1297148 0 0 0 0 0 0 0 4 152 0 0 1503 20208 1947 10 23 67
つまり、SYSが大きいけど、diskは少なめなのですね。想像通りです。
たしか、同じ物の検出のために、cryptoadmで登録されてるカーネルSHA1ライブラリを使っていると思うので、これをハードウェアオフロードするようなものがあれば、もっと高速になるかも知れませんね。
ちなみに、ノートのスペックは下記の通りです。
SYSが大きいってことで、念のため確認。
prstat -mL
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 5 root 0.0 27 0.0 0.0 0.0 0.0 73 0.1 70 14 0 0 zpool-rpool/13 5 root 0.0 22 0.0 0.0 0.0 0.0 78 0.2 57 10 0 0 zpool-rpool/39
てなわけで、ディスクI/Oを減らす代わりに、CPUを使うという結果になってることがわかります。
この結果は、ソフトウェアのチューニングパラダイムが、部分的に変わる可能性がありますねぇ。
多分、iSCSIでexportしたやつを、Linuxで使っても同じようにdedupがかかると思いますが、これはまた今度(笑)