这通常获取目录大小的方法是：
du -hs /path/to/directory
但是，它不起作用，我怀疑这是 btrfs 问题。据报告，带有子模块的子目录的大小超过了磁盘本身的总大小。
不过，我可以使用 gnome 磁盘实用程序检查磁盘是否有 60% 以上是空的。
通过进一步n检查
du -h --max-depth=n /path/to/folder
我能够将大子目录大小缩小到 btrfs 子卷，这就是为什么我认为这个问题与子卷有关
答案1
是的，这可能是 BTRFS 相关的问题。
一般来说，经典du对于 BTRFS 来说并不可靠，并且经常会给出这样看似荒谬的结果。这最终是因为（用于查看每个文件在磁盘上使用了多少空间的stat()系统调用）不知道也不关心引用链接、快照、透明压缩或 BTRFS 提供的除du标准 POSIX 语义。
这样做的影响是，du将计算通过引用链接在文件之间共享的所有块（其中包括已进行重复数据删除的任何块、由于使用克隆 ioctl 复制文件而共享的块以及属于快照一部分的任何块）。每个文件它保存对该块的引用，因此du可以显示明显的磁盘使用量远远大于实际的空间使用量。
我建议使用btrfs filesystem du而不是du，因为它会正确计算所有共享空间的使用情况。
另请注意，GNOME 磁盘实用程序df在处理 BTRFS 时也不完全可靠，但出于不同的原因（它们正确地考虑了引用链接，但不了解 BTRFS 使用的两阶段分配器，因此它们实际上可以将磁盘报告为大多数）即使您无法向其中写入任何内容，也为空）。因此，它们通常会显示与在du文件系统的根目录上运行所获得的使用值不同的使用值。 （如果您使用 ，情况会变得更糟du -x，因为这不会跨越子卷边界，因为它们看起来像安装点）。
答案2
正如 Austin 所提到的，诸如此类的工具du无法解释文件和子卷共享的范围。为此，需要一个支持 btrfs 的工具。
我专门为此目的编写了一个工具：
https://github.com/CyberShadow/btdu
btdu 将能够显示包含子卷或共享文件的其他结构的目录使用的唯一数据总量。要使用，请运行sudo btdu /path/to/your/volume/root，等待它积累足够的数据，然后下降到所需的目录。