ふと気づいた

NexentaStor、裏でZFSが動いているのですが、さらにそこのVMデータストアで重複排除（DeDupe)を有効にしています。移行中の過程で、あるバカでかいボリュームを抱えてるVMを一旦このデータストアに移し、その後別データストアに動かしました。

移動自体はうまく行ったのですが、あることに気づきました。

あれ、空き容量が全く増えてない・・

こりゃどういうことだろう？とおもって調べました

何故そうおもったの？

NexentaStorのGUI画面を採取しているのでそれを貼ります。
問題のVM移行が完了したのが確か3/20頃だったと思うのですが、Volume名「iSC-DS07」のAllocatedとFreeの値をご覧ください。

ちなみに問題のVM総容量はおよそ500GB程度。独自データというか、SQL ExpressやらWSUSやらが動いてるんで、あんまし類似ブロック多くないはずなんです。なので、少なくとも100GB程度の空きぐらいは出来るんじゃないかとおもってました。

【3/20ごろの様子】【3/21頃の様子】 【3/22ゴロの様子】 減るどころか増えとるという素敵なマジック。
当然「なんでやねん」と言うツッコミが胸の中で爆発しそうになったので、動きを調べてみました。

実は削除処理は動いてた

CLIでシェルモードにはいりました。で、調べてみると削除処理は一応動いていることを確認しました。zpoolコマンドを出力し、DDT情報を出力した結果が以下のとおりです。出力結果の最上段にあるのは、記録した時間をYYYYMMDDHHMM形式で書いてます。(Terapadにコンソール出力貼り付けー）

ほら、減ってる。最上段のDDTエントリ数だけで比較しても

■HAZE移行後、DDT上のエントリーが徐々に減ってる模様
 dedup: DDT entries 9809853, size 283 on disk, 154 in core
 dedup: DDT entries 9809673, size 283 on disk, 154 in core
 dedup: DDT entries 9808567, size 283 on disk, 154 in core
 dedup: DDT entries 9805377, size 283 on disk, 154 in core
 dedup: DDT entries 9803752, size 283 on disk, 154 in core
 dedup: DDT entries 9802624, size 283 on disk, 154 in core
 dedup: DDT entries 9800080, size 283 on disk, 154 in core
 dedup: DDT entries 9798997, size 283 on disk, 155 in core
 dedup: DDT entries 9759123, size 283 on disk, 155 in core

チョーっとチョーっとずつ減ってるのです。というわけで、削除してない・・・というわけではどうやらなさそうです。少なくともDDTのサイズは微減を続けています（今現在なお）

恐らく逆に容量が増えてるのは、他のVMによってボリューム使用量が増えてるだけなんだと思われます。

実は、恒常的に2MB/sec-3MB/secぐらいの書き込み処理が重複排除ボリュームにはかかっているようで、恐らくはこれがバックグラウンドで走ってる削除処理によるものではないかなと推察しています。

意外とメモリ負荷は高くない

FreeBSDなどでZFSを使用している方のブログなどで、「デカイファイル削除したらメモリ枯渇で死にそうになった」などの記載があったので一瞬ガクブルしたんですが、どうやらNexentaStorではそこらへん死なないように作られているようで、

■ARCのサイズはそんなに厳しくない
arc_meta_used = 940 MB
arc_meta_limit = 5118 MB
arc_meta_max = 1473 MB

arc_metaはarc総容量の1/4が割り当てられるため、まぁこんなもんかという感じなのですが、それにしてもメモリ使用量が少ないなぁと感じておりまして、もしかしたら、NexentaStorはこういうところ配慮して作られてるのかもしれませんね。

何にせよ注意しよう

今回の事象で理解できたことは

• インライン重複排除は削除処理が苦手
• インライン重複排除ストレージは、ファイルを作る/消すを頻繁にやる運用には不向き

ということでした。よくよく考えれば、インライン重複排除を許してる製品って大抵はバックアップ専門ストレージであることが多く、削除時はフラグのみ立てて、ある時点でバッチ処理による削除処理をガツーンとかけることが多いように思います。

ファイルサーバとして売られてるもので、重複排除が出来る製品はありますが、それらは重複排除処理そのものがスケジュールバッチで動いてることが多いです。Windows Serverの重複排除処理なんかそうですね。
何もしらんで、インライン重複排除ストレージをNASとして安易に売り出したら最後、「おい、ファイルを削除しても容量が空かんぞ、どないするんや」と激怒するお客様の顔が頭に浮かぶす。ファイル削除時の重複排除動作については、ちゃんとメーカーに確認をとったほうが良さそうです。
#とは言え、ちゃんと売られてる製品だったらその辺りちゃんとしてると思いますけどね。

インラインとバッチ式、それぞれの得手不得手を知ることができた良い機会かなと思いました。

重複排除処理のその後の流れについては、追って記載を進めていきたいと思います。