NTFSにゃドライブにdefragかけたら、
エラーが発生したため、ボリューム e (E:) は最適化されませんでした: パラメーターが間違っています。 (0x80070057)　で落ちる。
　何度やってもdefrag進捗率が50%にゃら50%という決まった場所で落ちるのでランダム性はにゃし。
　chkdsk /fしてみたがエラーは発見できず、結局直らにゃい。
　
　で、dedupかけてるドライブだったので
Start-DedupJob -Type GarbageCollection -Full　したら直った。
　
　format /Lしたセクタ4096のドライブで、vhdxをdedupして大量fragmentしてた状態だろうから、dedup上の不整合とかではにゃく、細かいファイルやフラグメントが一定以上に達したのでdefragが落ちたという予想が最も近そう。
　およそ重複排除に関しては、頻繁に重複排除とガベージコレクト、その後defragといったメンテをやらにゃいとダメそう。

　ボリュームをNTFSフォーマットしたら、セクタサイズが4096ににゃらずに8192ににゃってしまう。4096指定すると自動で8192に変更されるので、仕様の都合でそうにゃるらしい。
　にゃんでじゃ、と調べてみたら、容量制限がある模様。今時だと数TBのボリュームをNTFSフォーマットすると、セクタサイズが4096ににゃらず8192ににゃる。
　
　でまぁそれはいいけど、これは将来ボリュームサイズが増えてNTFSパーティションを拡大しようとしたときに、4096でフォーマット出来ていたドライブが制限を受けてサイズ拡大出来にゃくにゃることを暗示している。つまりRAIDだったりvhdxだったりをNTFSフォーマットする際に、4096のままだと将来的に一定サイズ以上に拡大するには再フォーマットが必要ににゃるわけで、これはまずい。
　
　で調べたら表ににゃってて、
　
　4k 16TB
　8k 32TB
　16k 64TB
　32k 128TB
　64k 256TB
　が最大らしい。
　
　実験してにゃいけど16TBを超えるNTFSボリュームはcompress効かにゃいってことににゃるんだろうか。
　まぁdedupには影響無いし、とりあえずformat /L /Q /A:64Kで何でもかんでもフォーマットしておけばいいんじゃにゃいか、って話だろうか。
　
　ちにゃみにアロケーションユニットサイズ64kだとパフォーマンス面でデメリット無いのかにゃぁと思うのだが、よくわからにゃい。微小ファイルの読み書きでI/O増えたりするのだろうか？全く増えにゃいのだろうか？

　vhdをSMB共有越しにマウントすると遅い。
　・・・全く同じ記事をちょっと前に描いてるのに忘れてる。
　
　*.vhdxをSMB共有しておいて、別PCでそれをマウントすることによって、メモリやCPUの豊富にゃPCで共有やdedup出来たり、vhdまるごと移動したりといった種々の利便があるのだが、デメリットも。
　まずそもそも速度が全く出にゃい。データ倉庫にする程度には使えるのだが、レイテンシとQueueの都合にゃのか何にゃのか、本来のI/O性能が出にゃい。例えばマウント側で大量I/Oを発生させると、見かけそのDiskはBusyににゃるのだが、Vhdxの共有側の物理I/Oは半分ほど余ってたりする。
　のと、
　別に遅くてもいいよねって思ってると、もっと何か遅くにゃったりした時にいろいろ致命的に遅くて、あらゆるアクセスが1000msかかったりして障害吐きまくる。これはあかん。
　いやそんにゃタイムアウトするほど遅くにゃるのがそもそもの原因ではあるが、たぶんネイティブにアクセスしてたら起きてにゃい。
　Hyper-VでvhdをSMB上に置きましょうとか言いまくってるからには何かチューンがあるのかもしれにゃいが、普通にやると結構あかん気がする。