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