我有一个工具（语言/实现无关紧要），它接受一个文本文件作为输入。这个文本文件（我们称之为file_list.txt）包含一长串文件路径，每行一个。然后，该工具遍历file_list.txt中的行，并对每个文件路径执行某些操作。这需要连续完成，file_list.txt需要始终包含最新的文件路径，因为用户不断上传或删除受监控共享中的文件。为此，我设置了一个调用脚本的cron作业。首先，脚本使用所需的搜索参数调用find实用程序，并将输出通过管道传输到临时文件。文件完全填充后，将移动到file_list.txt。然后，完成此操作后，将使用file_list.txt作为输入参数调用该工具。
到目前为止，这么好。被监视的共享非常大（约60 TB），find命令大约需要5个小时才能执行。这不是问题，因为我们有多个并行运行的重叠查找命令（每小时触发一次）。整个设置在计算服务器场上运行，因此CPU利用率等也不是问题。
问题出现在文件检测的延迟时间内。理想情况下，我希望用户添加一个文件，我希望其中一个已经运行的重叠查找命令在几分钟内检测到该文件。但是，我注意到没有一个已经运行的find命令会检测到这个文件。只有一个find命令启动 AFTER 此文件被添加后才能检测到它。这意味着通常，我需要等待大约5个小时才能检测到新添加的文件。这让我相信find实用程序在触发时以某种方式作用于共享状态的“缓存”版本。这是真的？谁能证实这一点？如果是这样，我该怎么做才能改善检测延迟？
如果需要进一步澄清，请告诉我。我很乐意提供任何进一步的细节。
答案 0 :(得分：1)
总结一下：你有一个巨大的文件系统卷（60 TB），其中包含大量文件，你使用find(1)命名大量这些文件并将这些名称放入文本文件进行分析。您发现如果文件是在find(1)启动后但在完成之前创建的，则不会列出文件。
我认为最好的解决方案是停止将其视为批处理作业，然后执行此操作＆＃34; online＆＃34;使用inotify(7)。您可以使用inotify API立即获知文件系统的更改，包括正在创建的新文件。当然有原始的C API，以及优秀的pyinotify。
使用inotify，您可以启动观察程序一次并使其连续运行（如果需要重启，则在主管下）。操作系统可以在发生相关文件系统事件时通知您，您可以立即响应而不是等待下一次扫描。
您的用例的一个缺点可能是观察程序确实需要在本地安装了文件系统的计算机上运行。但是，所需的总体计算资源可能远低于您当前的重复线性扫描方法。
答案 1 :(得分：1)
执行find命令并将输出传递给临时文件可能会达到一定的规模，但远非最佳。如果您想要资源消耗较少，反应更灵敏的解决方案，我建议您考虑使用inotify界面重新实现您的软件：
inotify API提供了一种监视文件系统事件的机制。 Inotify可用于监视单个文件或进行监视 目录。监视目录时，将返回inotify 目录本身的事件，以及目录中的文件。
因此，每个文件更改都会引发一个事件;或正在添加的文件。
请注意，您可以保留最新的内部文件列表，只有在您收到活动时才需要更改。