linux - "find"命令检测不到执行过程中添加的文件

Question

多年来，Stackoverflow 无数次救了我的命。现在，是时候发布我的第一个问题了，到目前为止我一直找不到答案。

我有一个接受文本文件作为输入的工具(语言/实现无关紧要)。这个文本文件(我们称之为 file_list.txt)包含一长串文件路径，每行一个。然后该工具遍历 file_list.txt 中的行并对每个文件路径执行一些操作。这需要不断地完成，并且 file_list.txt 需要始终包含最新的文件路径，因为用户不断地从被监控的共享中上传或删除文件。为此，我设置了一个调用脚本的 cron 作业。首先，脚本使用所需的搜索参数调用 find 实用程序，并将输出通过管道传输到一个临时文件。当文件完全填充时，它被移动到 file_list.txt。然后，一旦完成，将使用 file_list.txt 作为输入参数调用该工具。

到目前为止，还不错。被监控的共享非常大(约 60 TB)，执行查找命令大约需要 5 个小时。这不是问题，因为我们有多个并行运行的重叠查找命令(每小时触发一次)。整个设置在计算场上运行，因此 CPU 利用率等也不是问题。

问题出现在文件检测的延迟时间上。理想情况下，我希望用户添加一个文件，并且我希望其中一个已经在运行的重叠查找命令能够在几分钟内检测到该文件。但是，我注意到所有已运行的查找命令都不会检测到该文件。只有在添加此文件AFTER 后启动的查找命令才能检测到它。这意味着通常，我需要等待大约 5 个小时才能检测到新添加的文件。这使我相信 find 实用程序在触发时以某种方式作用于共享状态的“缓存”版本。这是真的？谁能证实这一点？如果是这样，我可以做些什么来改善检测延迟？

如果需要进一步说明，请告诉我。我很乐意提供任何进一步的细节。

Answer 1

总结一下:您有一个巨大的文件系统卷 (60 TB)，其中包含大量文件，您使用 find(1) 来命名大量这些文件并将这些名称放入到一个文本文件中进行分析。您已经发现，如果文件是在 find(1) 启动之后但在完成之前创建的，则不会列出这些文件。

我认为最好的解决方案是停止将其视为批处理作业，并使用 inotify(7) 在线完成.您可以使用 inotify API 立即获知文件系统的更改，包括正在创建的新文件。当然有原始的 C API，以及优秀的 pyinotify .

使用 inotify，您可以启动一个观察程序一次并让它持续运行(如果需要重新启动，则在监督程序下运行)。然后，操作系统可以在相关文件系统事件发生时通知您，您可以立即响应，而不必等待下一次扫描。

您的用例的一个缺点可能是观察程序确实需要在本地安装了文件系统的机器上运行。但所需的总体计算资源可能比您当前的重复线性扫描方法少得多。