这只是我的评论如何缓存或以其他方式加速“du”摘要？表述为一个自己的问题：
是否有关于创建一个文件系统的扩展讨论，其中每个目录的总大小（认为du）被保存并“冒泡”（即在树中向上传播，以便所有父目录大小也正确），例如由于写入文件、删除等，所以这du会是即时的吗？
从我上面链接的答案来看，很明显，这样做会导致 I/O 性能受到影响，我只是想知道影响有多大。它会减少几个数量级还是仅仅几个（十几）%？
与此密切相关的是以相同方式“冒泡”mtime 的概念，以便每个目录的 mtime 反映其整个子树内的最新更改。例如，对于具有许多深度嵌套文件的树，这两个功能一起可以显着加快rsync的模式。--update
答案1
现代文件系统（例如 zfs / btrfs / bcachefs）实际上朝着相反的方向发展，并允许/鼓励文件之间共享范围。这样，“目录占用多少数据”的概念变得不太明确（尽管由于硬链接，这在某种程度上已经是正确的）：使用引用链接，可以创建一个显然包含更多数据的目录甚至适合文件系统（至少就简单的磁盘分析工具（例如du或ncdu可以理解它）而言）。重新表述该问题的一种方法是“如果删除此目录，将释放多少可用空间”，这不太含糊，但不是很有用，因为一旦创建快照，大多数目录现在都会有一个唯一大小为 0（因为它们的数据也可以通过快照访问）。
我也遇到过这样的问题：
- 很难理解允许数据共享的文件系统上的空间使用情况
- 分析大型文件系统上的空间使用情况需要太多时间 (I/O)
为此，我创建了BTDU，一个采样磁盘使用分析器，它解决了 btrfs 的这些问题。
至于一般的“冒泡”概念：我不确定其他文件系统，但这实际上类似于 btrfs 内部工作的方式，其中有一个主根 (b-) 树递归地引用其他树。当更新任何树（许多级别深）时，新副本会写入磁盘上的其他位置（因此是 btrfs 的 COW 方面），并且父级会更新为指向新副本，这反过来会导致其父级在以此类推，直到根树。 （实际上，该实现采用了许多优化来保留其不变量，但保持合理的性能。）