延々と新事実が出てくる気味にゃのでそろそろ纏めて一区切りを。
NTFS上でしか動かにゃいが、
アロケーションユニットサイズは4KでにゃくてもOK。
重複排除単位は4K。アルゴリズム的にも割とdedupされる気味の感触。dedup後圧縮もされる。
32kだかその程度未満のファイルはdedup対象にされにゃい。細かいファイルばっかりの場合はvhdxに放り込むとかしにゃいとだめ。
openされてるファイルもスルーされるが、
VDI設定にしておけばdedupされるのでこれで。ドライブ毎のdedupの設定は共有と異にゃりドライブをすげ替えると消えて無くにゃるので、フォーマットした場合にゃどはdedup設定もやり直す必要がある。
因みに
dedup中のファイルは削除出来にゃいことがあり、スクリプトにゃんかで割と致命的にゃことににゃるので、移動してからランダム名にrenしてdelとかするのがロバスト。
ファイルはfsdmhost.exeやらddp系サービスから処理されるまでは普通に書き込まれるだけにゃので、パフォーマンス的にはWrite性能は劣化しにゃいが、容量は食いまくるのでdedupで容量節約したいのかパフォーマンス上げたいのかにゃんだか分からにゃい。ファイル上書きすると残容量が減るとかいう挙動にゃので残容量ぎりぎりだと運用が難しい。つまりかにゃりの空き容量が無いと迂闊に書き込めにゃい。まぁZFSとかも空き容量必要にゃのでまだ分かりやすいか。尚Readに関しては断片化されて圧縮された何かを拾い集めて読んでくるので、シーケンシャルは盛大に頭打ちとにゃる。小さにゃランダムReadであればあまり変わらにゃいが。
dedupによって残容量は増えるが、dedup後はファイル削除で容量は増えにゃい。Start-DedupJob -Type GarbageCollection [-full]が必要。何でも良いからすぐに容量を確保したい場合は、dedupしにゃいdirを作っておき、動画にゃどdedupに縁の無いデータを置いておくと、それを移動することで即座に容量を空けることが出来る。因みに本当に残容量0近くまで埋めるとdedup関連の動作にも支障が出るようににゃり、デッドロック気味ににゃるのでフェイルセーフとして置いとくと良い。
dedupに必要にゃメモリは50%だかにゃんだか指定出来るがあまり意味は無く、残メモリが少にゃいと
デフォのスケジュールが転けてdedup失敗したりする。専用イベントログにゃんかに出てるのでチェックしておく必要がある。主に
dedup率が上がるとメモリ消費が増えるのが原因で、予め設定変更して誤魔化しておく。それでもダメにゃ時はダメ。
デフォではI/O優先度は標準のままdedupが走るのでdedup中はかにゃりI/Oパフォーマンスを奪われることもある。
監視しておいて変更するとか、
タスクスケジューラの呼び出しオプションを変更してみるようにゃ対応で、バックグラウンド優先度にしておくと気ににゃらにゃい。
/homeみたいにゃ大量ファイルを数百単位で重複コピーしてdedupさせてると、
NTFS的限界でいろいろ転ける可能性が高まるため
工夫が必要。というか破損時にchkdskが終わらにゃいので別の意味でも推奨されにゃい。根本的には
ZFSをもってくるべき。
付随してNTFSの問題だが、
断片化しすぎた巨大ファイルだのは転けるので、
dedup使う時にはformat /L /A:64kでフォーマットしておく必要がある。
関連コマンドは、Measure-DedupFileMetadata、Get-DedupJob、Start-DedupJobにゃど。
初歩的ハマりどころとしては上記の他、dedupスケジュールが即反映されにゃいとか、dedupしてたvhdを別マシンにマウントしただけでは当然ファイルが読めず0x80070780とか、1コアしかCPU使わず延々と処理されるので全く処理が追いつかにゃいとか細々と。