我用了碎片整理程序整理我 100 GB 的 C:\ 驱动器上的可用空间，其中 85 GB 已满。整理碎片后，驱动器显示只有 75 GB 已满。10 GB 的可用空间是怎么神奇地出现的？我丢失了数据吗？
我在碎片整理之前清理了磁盘，垃圾只有大约 11 MB，所以这不可能是因为清理了临时文件。请注意，我对“可用空间”进行了碎片整理，这意味着它应该将空块重新排列为连续的。
答案1
可能发生的情况是碎片整理操作迫使 Windows 丢弃一些系统还原快照。如果元数据开销超出 Windows 通常使用的磁盘空间的 10%，那么这将是碎片化的病态情况。即便如此，我也不确定这是否可能。
我在 Defraggler 的版本历史或文档中没有看到任何内容表明它能够正确地对文件进行碎片整理以防止清除卷影副本。事实上，此主题来自 Defraggler 支持论坛的帖子表明他们知道发生了这种情况（论坛管理员在主题中发布了一篇标有“官方 Piriform 错误修复程序”的帖子），但没有表明他们是否会修复它。
对卷进行碎片整理时卷影副本可能会丢失：发生这种情况的原因是，默认情况下，VSS 默认使用 16 KB 簇，而大多数 NTFS 卷都使用 4 KB 簇进行格式化。因此，如果碎片整理操作移动的数据不是 16 KB 簇的倍数（或者移动的“距离”不是 16 KB 的倍数），那么 VSS 会将其视为更改并可能清除所有快照。
如果可能，请以 16 千字节 (KB) 为增量，按彼此对齐的块移动数据。这可以减少启用卷影副本时的写时复制开销，因为当发生以下情况时，卷影副本空间会增加，性能会降低：
- 移动请求块大小小于或等于 16 KB。
- 移动增量不是以 16 KB 为增量。
一个对用户来说不太明显的变化是我们在碎片整理期间对影子副本的优化。碎片整理有特殊的启发式方法，可以以最小化写入时复制活动和影子副本存储区域消耗的方式移动文件块。如果没有这种优化，碎片整理过程将加速删除较旧的影子副本。
答案2
每个片段都必须在某处进行跟踪。这需要存储空间（在文件系统的管道内，而不是您要直接访问的东西）。
举个例子：假设你有一个包含 1000 个片段的文件。因此你的文件是通过一组随机块存储的。而不是存储在单个连续块中。这意味着碎片文件在文件系统管道中需要 1000 倍以上的存储空间，即使只是为了存储每个片段的地址。文件系统管道将小字典/数据库/映射/表/列表保存到文件每个片段的位置。因此，对于文件系统管道，与 1000 个片段指针的列表相比，存储单个片段指针的列表不需要太多空间。
但是嘿，也许我错了......
编辑：支持信息来自这里：
当非常驻数据流过于碎片化，以致其有效分配图无法完全容纳在 MFT 记录中时，该分配图也可能存储为非常驻流，其中仅包含一个小的常驻流，其中包含指向非常驻数据流的有效非常驻分配图的间接分配图。
翻译：如果碎片严重，文件系统管道的一般情况假设将不适用。因此，FS 必须采取措施来容纳碎片，最终花费额外的存储空间，只是为了管理碎片。这正是我一开始的猜测。
编辑：鉴于上述情况，仅仅因为文件碎片就丢失 10GB 似乎还是太疯狂了。我敢打赌，在碎片整理时，你遇到了一些常见的文件系统损坏，这些损坏会自动得到纠正。我想你不仅有大量碎片，而且部分删除的文件占用了存储空间。如果能看到碎片整理的磁盘扫描日志（或在碎片整理之前运行磁盘扫描），那就太好了