Cドライブを最適化すると、空きディスク容量が10 GB増えたのはなぜですか？

Defragglerを使用して、100 GBのC：\ドライブの空き領域を85 GBいっぱいにデフラグしました。最適化後、ドライブの空き容量は75 GBのみになりました。10 GBの空き領域はどのように魔法のように表示されましたか？データを失いましたか？

最適化する前にディスククリーンアップを実行しましたが、ごみは約11 MBしかなかったため、一時ファイルのクリーニングが原因ではありません。「空き領域」を最適化したことに注意してください。つまり、空のブロックを連続するように再配置する必要がありました。

ntfs disk-space defragment

— ゴウェン
ソース

シャドウコピーとおそらく相互作用：（例えば参照piriform.com/docs/defraggler/technical-information/...）

— ホレイショ

また、デフラグには、デフラグする前にごみ箱を空にするオプションがあります。

— オクトーシテ

回答:

おそらく起こったのは、デフラグ操作により、Windowsがいくつかのシステム復元スナップショットを破棄することを強制したことです。Windowsが通常使用するものに加えて、メタデータのオーバーヘッドがドライブ領域の10％を占めるようになるのは、断片化の病理学的ケースです。それでも、可能かどうかはわかりません。

Defragglerのバージョン履歴やドキュメントに、シャドウコピーの削除を防ぐためにファイルを正しく最適化できることを示すものは何もありません。実際、Defragglerのサポートフォーラムのこのスレッドは、彼らがそれが起こっていることを知っていることを示しています（スレッドに「Official Piriform Bug Fixer」というラベルのボード管理者の投稿があります）が、修正するかどうかは示していません。

ボリュームをデフラグするとシャドウコピーが失われる可能性があります。これが発生する理由は、デフォルトでは、VSSはデフォルトで16 KBクラスターで動作し、ほとんどのNTFSボリュームは4 KBクラスターでフォーマットされるためです。したがって、デフラグ操作が16 KBクラスターの倍数でないデータを移動する場合（または移動する「距離」が16 KBの倍数でない場合）、VSSはそれを変更として追跡し、すべてのデータをパージする可能性がありますスナップショット。

MSDN：ファイルの最適化：

可能な場合、16キロバイト（KB）の増分で相互に整列したブロックでデータを移動します。これにより、シャドウコピーが有効になっているときのコピーオンライトのオーバーヘッドが減少します。これは、次の条件が発生すると、シャドウコピースペースが増加し、パフォーマンスが低下するためです。

移動要求のブロックサイズは16 KB以下です。

移動デルタは16 KBの増分ではありません。

Vistaの組み込みのデフラグはこれを行いません：

ユーザーにとって明らかでない変更の1つは、デフラグ中のシャドウコピーの最適化です。デフラグには、コピーオンライトアクティビティとシャドウコピーストレージ領域の消費を最小限に抑える方法でファイルブロックを移動するための特別なヒューリスティックがあります。この最適化がなければ、最適化プロセスは古いシャドウコピーの削除を加速します。

— 難民
ソース

この回答のスナップショットの部分については知りませんが、デフラグによってスペースが解放されたとは確信していません。デフラグによってごみ箱が空になりましたか？小さなファイルを単一のクラスターに結合しないファイルシステムでは、デフラグがそのようなスペースの増加にどのようにつながるかはわかりません。Windowsが数えていなかったような小さなブロックで10Gの空き容量があったと想像できますが、以前はその動作について聞いたことがありませんでした。

— -Slartibartfast

@Slartibartfast：アプリが正しく書かれていないと問題です。電話ではないので、より多くの証拠で回答を更新します。:-)

— フレイジャー

@afrazier-ThouArtNotDocの更新された答えは、より良い一般的な答えだと思いますが。私は、OPの状況でシャドウコピーがおそらく役割を果たしていることに同意する必要があります。「シャドウコピーが有効になっているボリュームを最適化する場合は、16 KB以上のクラスター（またはアロケーションユニット）サイズを使用することをお勧めします。そうしない場合は、変更の数最適化プロセスにより、シャドウコピーが予想よりも早く削除される可能性があります。」- MS：「シャドウコピー戦略の設計」technet.microsoft.com/en-us/library/cc728305(WS.10).aspxを

— Ƭᴇcʜιᴇ007

@afrazier：確認済み。以前のシステム復元ポイントはすべてなくなりました。構成では、シャドウコピーに許可される最大スペースとして12％が設定されているため、10 GBは不合理ではありません。一方、9 GBのゲームをインストールしただけで、以前の復元ポイントを単純に上書きしてしまう可能性がありました。

— -goweon

@firebat：システムの復元で使用される領域は、新しいファイルではなく、既存の（スナップショットされた）ファイルへの変更を追跡するためのものです。新しいゲームをインストールしても、システムの復元スペースには影響しませんが、大きなパッチは影響します。

— フレイジャー

各フラグメントはどこかで追跡する必要があります。それにはストレージスペースが必要です（ファイルシステムの配管内で、直接アクセスするものではありません）。

例：1000個のフラグメントを持つ単一のファイルがあるとします。したがって、ファイルはランダムブロックのコレクションを通じて保存されます。単一の連続したブロックではなく。これは、各フラグメントのアドレスを保存する場合のみ、断片化されたファイルがファイルシステムの配管内に1000倍のストレージスペースを必要とすることを意味します。ファイルシステムの配管は、ファイルの各フラグメントの場所に小さな辞書/データベース/マップ/テーブル/リストを保持します。したがって、ファイルシステムの配管では、単一のフラグメントポインターのリストを保存するのに、1000個のフラグメントポインターのリストと比較して、多くのスペースは必要ありません。

しかし、ちょっと、多分私は間違っている...

編集：ここからのサポート情報：

非常駐データストリームが非常に断片化されているため、その有効な割り当てマップがMFTレコードに完全に収まらない場合、間接割り当てを含む小さな常駐ストリームだけで、非常駐ストリームとして割り当てマップを格納することもできます非常駐データストリームの有効な非常駐割り当てマップにマップします。

翻訳：断片化が激しい場合、ファイルシステムの配管に関する一般的な仮定は適用されません。そのため、FSは断片化に対応するための措置を講じ、断片を管理するためだけに余分なストレージスペースが必要になります。そもそもまさに私の推測。

編集：上記を考えると、ファイルの断片化だけで10GBが失われているように見えます。デフラグ中に、一般的なファイルシステムの破損が自動的に修正されたことに賭けています。大規模な断片化だけでなく、ストレージスペースを占有する部分的に削除されたファイルもあると考えています。そのデフラグからのスキャンディスクログ（またはデフラグ前のスキャンディスクの実行）を見るのは良かったでしょう

— ジェームズ・T・スネル
ソース

PS-それはハードコアな断片化であったに違いありません。

— ジェームズTスネル

最適化後のストレージ消費量のこのような増加の正当な理由であるかどうかはわかりません。しかし、私はこれに何度も気づきました。非常に古いシステム復元ポイントがあり（ディスククリーンアップユーティリティを定期的に実行する場合は一般に発生しません）、Cドライブに多くのデータが収集された後にデフラグします、メモリ消費量はどこからともなく増加しますが、その復元ポイントを削除すると、占有されているストレージがクリーンアップされます。技術的には、意味をなさないかもしれませんが、時間の経過とともに復元ポイントがメモリを占有するため、何度も起こりました。

— クシャル

Dunno、10Gは多くのように見えますが、IME、非常にいっぱいのディスクは、断片化の少ないディスクよりもはるかに速く断片化する傾向があります。前に85％を超えていた場合（プロブは85GiBで100GBのディスクを意味していたため）、その間に満杯になる可能性があり、ひどく高い断片化と恐ろしいパフォーマンスがあった可能性があります。

— ベルントハウグ

そのボリュームのブロックサイズがひどく大きくない限り、断片を追跡しないだけで10GBのスペースが解放されるとは信じられません。ブロックサイズが4096kで、各フラグメントが追跡するだけで完全なブロックを必要とすると（これは誤りです）、以前は追跡されていた250万個のフラグメントが必要ですが、それ以上のスペースを解放する必要はありません。

— -CarlF

@Doc-ポインタはブロック全体を取りません。（おそらく）各割り当てブロックが複数のセクターである場合、データを追跡するブロックが少ないため、必要なポインターが少なくなります。したがって、すべてのフラグメントを追跡するための最大オーバーヘッドは3％をはるかに下回ります。NTFSの正確な詳細は知りませんが、（比較的非効率的な）FATファイリングシステムでは、FATの名前が付けられたファイルアロケーションテーブル（フラグメント追跡ポインター）のオーバーヘッドを10％得ることはできませんでした。

— Steve314