我正在尝试获取一份包含数 PB 基因组数据集的每日文件大小报告。我们当前的报告使用多个重叠du调用来实现结果，但执行时间超过 24 小时。我正在寻找一种更有效/更快/更“干净”地完成此操作的方法。
目前我们做的是：
# broad overview of dozens of projects + grand total
du -chd1 /petastorage/projects/
# detailed look at some 'special' projects,
# each of these has huge sub-dirs we want to track individually
du -hd1 /petastorage/projects/special_project_A/
du -hd1 /petastorage/projects/special_project_B/
du -hd1 /petastorage/projects/special_project_C/
让我感到困扰的是，它们special_project_[ABC]被抓取了两次，一次是在总体概览中，一次是在详细信息中。由于这些特殊项目占了数据的很大一部分，因此抓取两次它们大概（警告：假设）这是运行时的一个重要部分。另外，由于我们讨论的是 PB 级数据，我认为任何级别的文件系统缓存都不会加速重复调用。
我尝试过“优化”，
du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/
但它似乎du足够聪明，能够意识到特殊项目是第一个目录的子目录，因此它将它们“优化”到报告中。天哪！
有人知道我怎样才能说服du自己只抓取一次 PB 数据，同时单独输出所有项目以及三个“特殊项目”的（更深一层的）详细视图
注意：当前的 du 输出已经经过某种 sort/uniq 管道处理，使其显示更美观，并且在电子邮件报告中没有重复项，因此涉及后处理的解决方案是可以接受的。与statPB 级的旋转 rust 相比，任何后处理运行时间都是零。
背景信息（以防万一）：这是在 OpenSuse 11.4 上安装到 EMC-isilon 存储节点的 NFSv3。所有项目目前共享 isilons 上的单个存储池，因此可以在项目之间转移可用空间。由于其规模，将“特殊”项目移动到它们自己的文件系统以便我们“作弊”是df不可行的。
答案1
在花了一两天时间解决这个问题后，我们决定选择简单的方法，暂时不再进行优化。最终，开发人员的时间比脚本运行时间更昂贵。
如果/当我回到这个问题时，我可能会对du子项目运行一次，du对大文件夹运行第二次（使用--exclude第一个文件夹涵盖的项目），然后在后期处理中手动计算总计（明智地使用awk，sed或grep | paste -sd'+' | bc就足够了）
如果其他人有更好的想法，我很乐意听到:-)
答案2
报告说，作为更大规模存储重新架构的一部分，我们已经走上了“不可行”的路线。
我们的新文件服务器支持每个子挂载的配额，因此随着时间的推移，我们一直在将项目提取到子挂载中，而不是大型共享文件系统/挂载中的“普通”文件夹。这是一个持续数周/数月的后备迁移项目。这使我们能够对所有所需的“文件夹”设置配额。
我们现在查询配额状态（由文件服务器实时即时管理）