つぶねこ

　延々と新事実が出てくる気味にゃのでそろそろ纏めて一区切りを。
　
　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使わず延々と処理されるので全く処理が追いつかにゃいとか細々と。

　Win8のメインPCでHyper-Vのvmをいろいろ起動させて放置したら、メモリを食い尽くしてあちこちのサービスが落ちたり小さにゃプロセスも起動できにゃくにゃってたりとか。
　原因は動的メモリで確保してたせいと思われる。vm内部でメモリ要求があればその分確保しようとするのだろう。ただペアレントパーティションのサービス類まで落ちるというのはちょっと優先度がおかしい気がするが・・・vm内部のサービスは影響受けてにゃいようだし。
　
　でまぁ確認してみたら動的メモリで確保する方が物理メモリ消費量多かったりして、もうちょっと上限定めた設定にするか、さっくり固定容量で確保した方がマシかにゃといった感じ。
　このあたりのメモリ管理はまだまだvmwareに追いついてにゃい。メモリ足りにゃいと起動できにゃいって仕様もどうかと思ってたが、ほっといたら自滅するだにゃんて・・・

　Hyper-V母艦のWin8が2回も青画面出したので見てたのだが、Hyper-VのVMを再起動するとcritical_process_died BSODに。何度やってもVMがBSODで起動してこにゃい。
　ちょっとレア事象すぎるので他のVMも再起動したらBSOD・・・
　別ドライブにコピーしてもBSODににゃるのでこれは何が原因にゃのか悩ましい。
　vm上でsfc /scannowすると正常終了しにゃい。
　切り分けのため別SSDに新規にWin8を入れてみたら、これもきっちりVMがBSODする環境が出来上がった。さいげんせいはばっちりだ・・・
　
　というところで時間切れしてきたのだが、Hyper-V母艦でVM動かにゃいとか存在価値無くにゃってるので何とかする必要が。
　現状残ってる可能性とにゃると、SSDをつにゃげてるオンボードのSAS RAIDを一度無効化してみるとかか。
　にゃんちゅう面倒にゃ・・・