为什么当空间明显足够时 xcopy 会失败？
我有一个 2TB 硬盘驱动器“D”，其中包含 2TB NTFS 分区上的 732GB 数据，我想将其（绝对是驱动器上的所有内容）复制到另一个具有 981GB 空间的驱动器“F”（其刚格式化 (NTFS)）。
我确保没有进程写入磁盘 D 或 F。只有一个备份进程正在运行（backblaze），我认为它只执行读取操作，所以应该没问题。
我通过管理员提升的命令提示符开始复制：
C:\Users\Me\Desktop\: xcopy /x /o /h /e /k D: F:
然后大约 20 小时后，该命令失败并显示“空间不足”。我检查了资源管理器，磁盘 F 确实 100% 已满。磁盘D没有增长或任何东西，仍然只有732GB在使用。
我在这里一窍不通。为什么数据突然变大了？我应该尝试使用诸如 clonezilla 之类的 live cd 吗？
（附带问题：我可以以某种方式加快这个过程吗？）
更新 1
根据建议，我尝试了以下操作：
robocopy D:\ F:\ /COPYALL /E /DCOPY:T /R:10 /LOG:copylog.log /XD .bzvol
我排除了.bzvol（只有 82 KB），因为如果我不这样做，它会混淆 backblaze！
一旦 F 已满，这将导致“无休止地”重复此消息： ERROR 112 (0x00000070): There is not enough space on the disk. Waiting 30 seconds...
以下是一些视觉证据：
我检查了驱动器 D未设置为“压缩此驱动器以节省磁盘空间”。
驱动d是由TrueCrypt的7.1A加密。我正在复制时，它当前已安装。但我认为，这不应该是这里的一个因素。
更新 2
根据新的反馈，我收集了关于这两个分区的一些统计数据。查尔的钱是对的。目标磁盘上的集群大小明显更大。我想知道这两者中的哪一个是两者的“正确”（更好）设置，但是为了复制成功，我无论如何都没有太多选择。谢谢大家的帮助。
小智 6
源卷 D（实际上是 TrueCrypt 容器内的文件系统）和目标卷 F 上的集群大小（分配单元大小）是多少？
驱动器填满的一种假设是卷 F 具有更大的簇大小，而卷 D 具有许多小文件。这意味着相同的数据在目标卷 F 上可能比在源卷 D 上占用更多的空间。