zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。
　zfsとntfsのdedupの違いは過去にいろいろメモったが、要するにzfsは雑だしntfsは遅くて頻繁に膨らむので、現状どっちもどっちと。
　というわけで多重化してみましょうという実験。
　zfs compressは通常にゃら大変使い勝手の良いオプションだが、dedup効率は落ちるのと、vhdxはより一層dedupしづらい物体とにゃるので却下。zfs dedupだけ使用する。
　zfs dedupによってオンラインで巨大データの書き込みがdedupられるのでntfsのように一時的に膨大にゃ空き容量を必要としにゃい。但しメモリは多めに持たせておかにゃいと怖いが。
　そんにゃzfs on linuxにゃvmをhyper-vでホストしてntfs dedupにかける。zfs側で大量の書き込みがあるとその分膨らむが、ある程度dedupされた後にゃのでそこまで深刻にゃことににゃりにくい。
　
　という夢を見たのでやってみる。

zpool create pool1 sdb
zfs create -o recordsize=4k pool1/share
zfs set atime=off pool1/share
zfs set primarycache=metadata pool1/share
zfs set dedup=on pool1/share
zfs set snapdir=visible pool1/share

　4kの指定は過去に膨大にゃI/Oを発生させて死亡する原因とにゃったのでzfs on linuxでも実験である。
　これでrsync hoge /pool1/share
　で放置してたら途中で

blk_update_request: critical target error

　吐いて停止。リセットかけたら長時間disk readしたあとカーネル落ち。再リセットで復帰した。傾向は変わってにゃい模様。
　4k指定しにゃければ割と安定感があるのだが、可変にさせるとdedup効率が落ちるパターンが多いんだよね。
　しかし今回はvhdxをさらにdedupするので、

zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool1/share

　で行けるのでは無いかと実験。今のところ安定している。この場合recordsizeは別に無指定で良いとは思うがにゃんとにゃく。
　ashift=16にゃんかにするとどうにゃるのかという興味もあるが、NTFS側で4kブロックでdedupされるにゃら変わらにゃい可能性の方が高いか。