哥们，这情况我之前帮朋友排查过类似的，结合你的测试数据和现象来看，问题基本锁定在NTFS文件系统本身的特性以及挂载配置上，给你拆解几个核心原因：

1. NTFS元数据遍历的额外开销 #

du命令的核心是遍历文件系统的元数据来计算文件大小，而NTFS的主文件表（MFT）结构和Linux原生文件系统（比如ext4、XFS）差异很大。Linux下的NTFS驱动（常用的是ntfs-3g）需要在NTFS的MFT记录和Linux虚拟文件系统（VFS）的接口之间做大量转换，尤其是当你的备份目录里存在大量小文件时，元数据的读取、解析开销会被指数级放大——这也是为什么排除NTFS磁盘后，相同大小的目录仅需3秒就能完成统计的核心原因。

2. 挂载参数未做优化 #

检查一下你fstab里的NTFS挂载项，默认的defaults参数可能没有开启关键优化：

• 未添加noatime：du遍历文件时会触发访问时间（atime）的更新，每次更新都要写入NTFS元数据，而NTFS的元数据同步开销远大于原生文件系统，累加起来会拖慢整个过程。
• 未启用big_writes：虽然你的测试写入速度是135MB/s，但这个参数能提升大文件的写入效率，间接减少元数据操作的等待时间。
• 磁盘开启了压缩：如果NTFS是压缩状态，du需要实时解压文件来计算实际大小，这会额外消耗大量CPU和IO资源。

3. NTFS驱动的性能瓶颈 #

Linux上的NTFS驱动属于第三方实现（ntfs-3g），相比原生文件系统驱动，它在处理大规模文件遍历、元数据批量读取时的效率天生就低。你测试的裸盘IO速度是硬件极限，但实际文件系统操作需要经过驱动层的转换，这个转换层的开销在大量文件场景下会被无限放大。

4. 文件系统碎片问题 #

如果你的NTFS磁盘长期使用未做碎片整理，MFT记录和文件数据可能分散在磁盘的各个位置。du遍历文件时需要频繁随机寻道，虽然裸盘连续读取速度高达6.9GB/s，但随机读取的寻道时间累加起来，会让总耗时飙升到几十分钟。

快速验证与解决建议 #

• 调整挂载参数：修改fstab里的NTFS挂载项，添加noatime,big_writes，执行mount -o remount /path/to/ntfs重新挂载后，再跑du -h --max-depth=1 | sort -h测试耗时。
• 整理磁盘碎片：用ntfsdefrag工具对NTFS磁盘做碎片整理，完成后再测试命令速度。
• 统计文件数量：用find /path/to/ntfs -type f | wc -l统计文件总数，如果是几十万级别的小文件，建议把备份目录迁移到Linux原生文件系统（比如ext4）上，从根源解决性能问题。

内容的提问来源于stack exchange，提问作者djfrickert