NTFSでの圧縮システムイメージの極端な断片化の回避
問題の説明
Wbadminで作成したWindowsディスクイメージをNTFSドライブに保存していますが、NTFS圧縮で圧縮すると、1.5〜2倍のスペースが節約され、復元を完全に利用できることがわかりました。
しかし、圧縮の過程で、ファイルはめちゃくちゃに断片化されます。通常、システムディスクイメージの断片は100,000を超えます。
このような断片化では、最適化に非常に長い時間がかかります（画像ごとに数時間）。一部のデフラグメンターはそれを処理することさえできず、ファイルをスキップするかクラッシュするだけです。
問題の原因は、ファイルが個別に保存されるチャンクによって圧縮されていることだと思います。
質問
画像ファイルをデフラグし、圧縮したままにする（または極端な断片化を引き起こさずに圧縮する）ための良い（高速な）方法はありますか？ファイルを連続的な空き領域にすばやくデフラグするユーティリティ、または既存の非圧縮から非フラグメント化された圧縮ファイルを作成するユーティリティ（またはメソッド）でしょうか？
コメント/回答に基づくコメント：
- 私の場合、外部（Windowsカーネルへの）圧縮ツールはオプションではありません。その場でファイルを解凍することはできません（10 Gbファイルを解凍するには、10 Gbの空き容量が必要ですが、常に手元にあるとは限りません。また、時間がかかります）。システムがリカバリのためにDVDから起動しているときは、アクセスできません（イメージが必要なときです）。
compact.exeのように、ntfsでトランスアプレント圧縮ファイルを作成しない限り、提供を停止してください。 - NTFS圧縮は、システムイメージにとってそれほど悪くはありません。断片化を除けばかなり良いです。また、解凍にはCPU時間があまりかからず、IOボトルネックが減少し、適切な場合にパフォーマンスが向上します（断片化されていない圧縮ファイルでかなりの比率）。
- デフラグユーティリティは、ファイルが圧縮されているかどうかに関係なく、ファイルをデフラグします。唯一の問題はフラグメントの数であり、フラグメント化されたファイルが圧縮されているかどうかに関係なく、デフラグが失敗します。フラグメントの数が多くない場合（約10000はすでに問題ありません）、圧縮ファイルはデフラグされ、圧縮されたままの状態に保たれます。
ファイルによっては、NTFS圧縮率が適切な場合があります。システムイメージは通常、元のサイズの最大70％に圧縮されます。
それらのスクリーンショットのペアは信じていませんが、多くの場合、独自のテストを行うことができます。
![]()
![]()
私は実際に、断片化されたものと断片化されていないものの両方のNTFS圧縮イメージから復元を行いました。それは機能します。信頼するか、自分で確認してください。 rem：1年ほど前に見つけたように、Windows8.1では機能しません。それはWindows7、8、および10で動作します。
期待される答え：
windows用の作業方法またはプログラムは次のいずれかになります。
多くのフラグメントを作成せずにファイルを圧縮し（NTFS圧縮を使用し、Windowsリカバリからアクセスできるようにします）（おそらく別のパーティションに保存するか、圧縮コピーを作成します。HDDでは
compact+defragより少なくとも3倍高速である必要があります）、または
10万以上のフラグメントを含むファイルのように、断片化されたファイルをすばやく（HDDのWindowsデフラグよりも少なくとも3倍高速に）デフラグします（デフラグ後も圧縮されたままである必要があります）。
断片化の回避
その秘訣は、そもそも非圧縮ファイルをディスクに書き込まないことです。
実際、既存の大きなファイルを圧縮すると、NTFSインプレース圧縮アルゴリズムの性質上、ひどく断片化されます。
代わりに、OSにファイルのコンテンツをディスクに書き込む前にオンザフライで圧縮させることで、この欠点を完全に回避できます。このようにして、圧縮ファイルは通常のファイルと同じようにディスクに書き込まれます-意図しないギャップはありません。この目的のために、圧縮フォルダを作成する必要があります。 （ファイルに圧縮のマークを付けるのと同じ方法で、フォルダーに圧縮のマークを付けることができます。）その後、そのフォルダーに書き込まれるすべてのファイルがオンザフライで圧縮されます（つまり、圧縮ブロックのストリームとして書き込まれます）。この方法で圧縮されたファイルは、最終的には多少断片化する可能性がありますが、インプレースNTFS圧縮によって発生する混乱とはかけ離れています。
例
NTFS圧縮232Mbシステムイメージから125Mb：
- インプレース圧縮により、なんと2680フラグメントが作成されました！
- オンザフライ圧縮により、19フラグメントが作成されました。
最適化
NTFS圧縮ファイルが一部のデフラグツールに問題を引き起こす可能性があるのは事実です。たとえば、私が通常使用するツールはそれらを効率的に処理できません-それはクロールまで遅くなります。古い信頼できる Contig fromSysinternalsは、NTFS圧縮ファイルをすばやく簡単に最適化する役割を果たします。
NTFS圧縮 に関するウィキペディアの記事を読む：
ファイルは16クラスターのチャンクに圧縮されます。 4 kBクラスターの場合、ファイルは64kBチャンクに圧縮されます。圧縮によって64kBのデータが60kB以下に減少した場合、NTFSは不要な4kBページを空のスパースファイルクラスターのように扱います。これらは書き込まれません。
これにより、合理的なランダムアクセス時間が可能になります。OSはフラグメントのチェーンをたどるだけで済みます。
ただし、64KB未満のすべてのチャンクがフラグメントになるため、大きな圧縮可能ファイルは高度にフラグメント化されます。
まず最初に。 WBAdmin は本質的に、システム全体をカム復元するバックアップユーティリティです。そのため、出力ファイルは大きい（> 4Gb）と予想されます。引用で示されているように、大きなファイルは急速に断片化されます。これは、NTFSの圧縮方法（ファイルではなくセクターによる）によるものです。
良い例えは、ケーキがいくつかのボックスに分割され、そのうちのいくつかは空ではないというものです。これが初期ファイルです。圧縮部分がケーキを絞り、箱の中にスペースを残します。ケーキが合わないため、空間ができて、ケーキを構成するピースが細かくなります。
私はまだNTFSがそのような圧縮率を出すことに懐疑的です。複数のファイルに対して MaximumCompression によって行われたテストによると、NTFSは圧縮率で最低のスコア（わずか40％）を取得します。個人的な経験から、それはそれよりはるかに低いと言うことができます、実際、私はそれを使うことを気にせず、その効果を見たことがないほど低いです。
断片化を回避する最善の方法は、NTFSへの依存をやめることです。ほとんどのデフラグは、圧縮ファイルの展開または移動に失敗します。どういうわけか、NTFSはファイルを展開できませんでした。または、可能であれば、デフラグプロセスによって圧縮（4kB）の残りのスペースが埋められるため、ファイルがフラグメント化されないため、展開によってファイルがフラグメント化されます。隣接する前のクラスターに書き込まれます。
そうは言っても、ファイルを常に読み取る必要がない場合は、上記のリンクで推奨されている形式のいくつかを使用してください。 7zとrarは非常に効率的です（つまり、適切な時間に高い比率で圧縮されます）。時間ではなくスペースを重視する場合は、PAQタイプのアルゴリズムを選択してください（ただし、ファイルの圧縮と解凍には非常に長い時間がかかります）。利用可能な高速アルゴリズムもあります。
ファイルを常に読み取る必要がある場合は、圧縮しないでください。 NTFSは非常に厄介です。
OPが尋ねたものとは正確には異なりますが、Paragonという名前のサードパーティソフトウェアで良い経験をしました。 NTFSは、定義上、ファイルを圧縮（または場合によっては書き込み）すると、ファイルシステムをひどく破壊します。これは、複数のMFTエントリの消費にまで及びます...それは悪いことです。 MicrosoftのNTFSドライバは、ファイルが最適化されてもこれをクリーンアップしません。したがって、サードパーティのツールが必要です。 Paragonを使用すると、それ自体をOS（ISOイメージ）として起動するか、ターゲットファイルシステムにアクセスできる別のWindowsOSにインストールできます。次に、MFTとファイルの両方を最適化できます。私の知る限り、これは、ボリュームを再フォーマットする以外に、NTFSのこの欠陥を修正する唯一の方法です。
（実際に機能することがわかったのはそれだけである以外は、ツールやその作成者とは関係ありません）
質問があったように見えてから2年後の今日、重複排除をお勧めします。これにより、イメージが「少し」異なる場合に、ディスクを90％以上節約できます。 VM内のW2016ナノサーバーは本当にうまく機能しますが、FreeNASまたはZFSを使用する他のものでさえそれを処理できると思います。