首先：还有很多其他有用的问题（例如这和这df) 讨论了和报告的不同尺寸的可能原因du。然而，这些解释都不适用于我这个极其简单的案例，因此出现了这个新问题。
我有一个非常简单的场景：我有两块相同的 5 TB Seagate 硬盘，它们是同时购买的（几个月前），原始格式为 NTFS。硬盘 A 中存有几千个文件（大多为 GB 大小），FreeFileSync 每晚用于将硬盘 A 镜像到硬盘 B。
从第一次镜像开始，我就发现驱动器 B 上的文件比驱动器 A 上的文件占用了近 3% 的空间，这种情况一直持续到现在（几个月后）。相同文件两者均有df报告（以 512 B 块为单位）：
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk4s2 9767276536 8946736496 820540040 92% 6149 4294961146 0% /Volumes/A
/dev/disk5s2 9767276536 9199664896 567611640 95% 5719 4294961576 0% /Volumes/B
而du -d 0每个驱动器的根目录中的报告（同样以 512 B 块为单位）仅有 0.002% 的差异：
A: 8939999664
B: 8940229723
因此，我试图找出可能导致驱动器 B 上的可用空间减少 3% 的原因——这两个 5 TB 驱动器之间的差异为 121 GB。
我排除了在其他地方找到的所有建议——这不是文件碎片的问题，因为du显示类似的块使用情况，没有任何类型的符号链接或硬链接，没有安装任何卷，没有隐藏日志，我没有用完 inode，我du以 root 身份运行，没有标记为删除的文件仍具有打开的句柄，.Trash两者的根文件夹都是空的。我读过du不计算目录本身和其他文件系统数据使用的块，但我看不出这怎么会导致 121 GB 的丢失空间——而且驱动器之间的目录显然是相同的，总共只有大约一千个目录。当我验证文件系统时，两个磁盘都没有显示错误。我想知道问题是否可能是坏块，但我似乎找不到任何关于如何检测文件系统是否已经对此进行补偿的参考。这些磁盘也相当新，差异从第一天开始就存在。
这个问题至关重要，因为当文件添加完毕后磁盘 A 几乎满了，镜像就会失败，因为磁盘 B 会先用完空间。我暂时“解决”了这个问题，方法是使用磁盘 B 进行写入，使用磁盘 A 进行镜像，以避免出现该问题，但我仍然想了解到底是什么使用了神秘的 121 GB 空间。