为什么对C驱动器进行碎片整理会增加10 GB我的可用磁盘空间？

我使用Defraggler对100 GB C：\驱动器（已满85 GB）上的可用空间进行碎片整理。进行碎片整理后，驱动器仅显示75 GB的完整空间。10 GB的可用空间是如何神奇地出现的？我有没有丢失任何数据？

我在进行碎片整理之前先进行了磁盘清理，而我的垃圾桶只有大约11 MB，所以不能因为清理临时文件而已。请注意，我对“可用空间”进行了碎片整理，这意味着它应该已经将空块重新排列为连续的。

可能发生的情况是，碎片整理操作迫使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的内置碎片整理功能无法执行此操作：

对用户而言不明显的一项更改是我们在碎片整理过程中对卷影副本进行了优化。Defrag具有特殊的试探法，可以以最小化写时复制活动和卷影副本存储区消耗的方式移动文件块。如果没有这种优化，则碎片整理过程将加速旧卷影副本的删除。

每个片段都必须在某个地方进行跟踪。这会占用存储空间（在文件系统的管道中，而不是您直接访问的东西）。

一个示例：假设您有一个包含1000个片段的文件。因此，您的文件是通过随机块的集合存储的。而不是单个连续块。这意味着，如果仅用于存储每个片段的地址，则碎片文件需要在文件系统的管道内增加1000倍的存储空间。文件系统管道对文件的每个片段的位置几乎没有字典/数据库/映射/表/列表。因此，对于文件系统管道而言，与包含1000个片段指针的列表相比，存储单个片段指针的列表不需要太多空间。

但是，嘿，也许我错了...

编辑：来自这里的支持信息：

当非居民数据流过于零散，以致其有效分配图不能完全适合MFT记录时，分配图也可以存储为非居民数据流，只有一个小的居民流包含间接分配映射到非居民数据流的有效非居民分配图。

翻译：如果您有大量碎片，则文件系统管道的一般情况假设将不适用。因此，FS必须采取措施来容纳碎片并最终花费额外的存储空间，仅用于管理碎片。从一开始我就是我的猜测。

编辑：鉴于上述情况，似乎10GB只是由于文件碎片而丢失是疯狂的。我敢打赌，在进行碎片整理时，您会遇到一些常见的文件系统损坏，这些损坏会自动纠正。我在考虑的不仅是大量碎片，而且部分删除的文件会占用存储空间。很高兴看到该碎片整理中的磁盘扫描日志（或在磁盘碎片整理之前运行磁盘扫描）