多年来,Stackoverflow挽救了我很多命。现在,该是我发布我的第一个问题的时候了,到目前为止我还无法找到答案。

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

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

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

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

最佳答案

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

我认为最好的解决方案是停止将其视为批处理作业,而使用 inotify(7) “联机”完成。您可以使用inotify API来立即获悉文件系统的更改,包括正在创建的新文件。当然,还有原始的C API和出色的pyinotify

使用inotify,您可以启动一次观察程序并使其连续运行(如果需要重新启动,请在 super 用户之下)。然后,只要有相关的文件系统事件发生,操作系统就可以通知您,并且您可以立即做出响应,而不必等待下一次扫描。

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

10-07 19:28
查看更多