我们有一个大型文件系统，完整的du（磁盘使用情况）摘要需要两分钟多的时间。我想找到一种方法来加快该文件系统上任意目录的磁盘使用情况摘要。
对于小型分支，我注意到du结果似乎以某种方式被缓存，因为重复请求要快得多，但在大型分支上，速度可以忽略不计。
是否有一种简单的方法可以加快速度du，或者更积极地缓存自上次搜索以来尚未修改的分支的结果？
或者是否有替代命令可以更快地提供磁盘使用情况摘要？
答案1
du通过使用 可以极大地加快 的常见使用速度ncdu。
ncdu - NCurses Disk Usage
执行du，缓存结果并在一个漂亮的命令行 GUI 中显示它们，有点类似于du -hc -d 1 | sort -h.初始索引花费的时间与 一样长du，但查找填充宝贵空间的实际“罪魁祸首”的速度会加快，因为所有子目录都有最初缓存的 du 信息可用。
如果需要，可以按 刷新子目录R，按 删除文件/文件夹D，这两者都会更新所有父目录的统计信息。删除要求确认。
ncdu -1xo- / | gzip >export.gz如有必要，可以通过在 cronjob 中预先缓存并稍后使用 访问它来实现进一步的加速zcat export.gz | ncdu -f-，但显然会提供更多过时的信息。
答案2
重新运行 du 命令时您看到的是磁盘缓冲的效果。一旦读取了一个块，其磁盘缓冲区就会保留在缓冲区高速缓存中，直到需要该块为止。对于 du，您需要读取目录以及目录中每个文件的索引节点。在这种情况下，du 结果不会被缓存，但可以用少得多的磁盘 IO 来导出。
虽然可以强制系统缓存此信息，但整体性能会受到影响，因为所需的缓冲区空间无法用于主动访问的文件。
目录本身不知道文件有多大，因此需要访问每个文件的inode。为了使缓存值在每次文件大小更改时保持最新，需要更新缓存值。由于一个文件可以在 0 个或多个目录中列出，因此需要每个文件的 inode 知道它在哪些目录中列出。这将使 inode 结构大大复杂化并降低 IO 性能。此外，由于 du 允许您在假设不同块大小的情况下获得结果，因此缓存中所需的数据需要为每个可能的块大小增加或减少缓存值，从而进一步降低性能。
答案3
duc
（看https://duc.zevv.nl）可能就是您正在寻找的。
Duc 将磁盘使用情况存储在优化的数据库中，从而实现快速的用户界面。索引完成后无需等待。
更新索引对我来说非常快（121k 目录中的大约 950k 文件，2.8 TB，不到 10 秒）。还有一个 GUI 和一个 ncurses UI。
用法例如：
duc index /usr
duc ui /usr
来自网站：
Duc 旨在扩展到大型文件系统：它将毫无问题地索引和显示 PB 存储上的数亿个文件。
答案4
如果您可以安排文件的不同层次结构属于不同的组，则可以设置磁盘配额。除非您需要，否则不要给出上限（或将其设置为磁盘大小）。您仍然可以立即知道该组正在使用多少（实际上是无限的）配额。
这确实要求您的文件系统支持每组配额。 Linux 的 Ext[234] 和 Solaris/*BSD/Linux 的 zfs 都是如此。如果组配额考虑到 ACL，这对您的用例来说会很好，但我认为它们不会这样做。