我在 Windows Server 2008 系统上有一个格式化干净的 8TB NTFS 驱动器。我正在使用一些并行 robocopies 将 6TB 的文档复制到该驱动器上。有大量较小的文件（约 1.5 亿个）。这些文件分布在多个目录中。总体而言，文件太大，无法内联在 MFT 中。大约四分之三的复制过程，复制性能显著下降。
查看 procmon，似乎瓶颈是 MFT 扩展。我看到每个 robocopy 进程在 CreateFile 上花费约 3.5 秒。在发出第一个调用后，我立即看到 $Mft 上的 IRP_MJ_READ 返回 END OF FILE。就在 CreateFile 成功之前，我看到另一个 $Mft 读取成功。
一些相关信息：MFT 已经很大~115GB。但是这远小于驱动器的默认预留空间 12.5%。MFT 正在快速碎片化。Contig.exe 报告了 100,000 个碎片。新碎片被频繁添加（每秒多次）。
我的问题：
我可以让 MFT 扩展为更大的块吗？
我很好奇为什么 MFT 会碎片化，尽管它远低于预留大小。我知道 MFT 不是从预留大小开始的，但如果它不能连续增长到预留大小，那么预留有什么意义呢。驱动器上仍有 33% 的可用空间，因此普通数据不应该使用预留空间。
更新 fsutil fsinfo ntfsinfo 为 MFT 提供以下信息：
Mft Valid Data Length: 0x0000001ca90c0000
Mft Start Lcn: 0x0000000000000000
Mft Zone Start: 0x000000003c828360
Mft Zone End: 0x000000003c828380
区域很小，这是正常的吗？
答案1
SysInternals contig 的最新版本可以报告可用空间。
contig64 -f
表明：
Free cluster space : 2,838,753,701,888 bytes
Free space fragments : 89,747,382 frags
Largest free space block : 90,112 bytes
我认为这解释了一切。尽管有超过 2TB/8TB 的可用空间（25%），但可用空间完全碎片化。这将影响 MFT 的增长，目前我除了查看碎片整理选项外无能为力。
我不确定是否有办法可以避免这种情况。感觉你应该能够将已知大小的文件并行复制到新格式化的磁盘，而不会产生这种程度的碎片。