为了递归地观看我的主目录和所有子目录 60 秒：
$ inotifywatch -v -r -t 60 /path
您可能会收到Failed to watch /path; upper limit on inotify watches reached!错误，您可以通过提高限制来修复该错误，例如升至 128k：# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
这让我想知道：
拥有 n 块手表会带来哪些具体成本inotify？
我问两个问题：具体和渐近的复杂性成本（我还没有挖掘，内核堆栈的哪些部分的数据结构以及如何与 inotify 的实现挂钩）。
我的意思是：计算、内存和其他成本。
我想，这些是函数（给出以 KiB 为单位的具体数字，或 CPU 负载的估计（也许有一些好的基准），甚至是渐近的（例如“每个 io ））：
- 观看的文件/目录
- 对文件/目录执行的操作
- inotify 监视队列的长度
但也许我错过了什么？
我还没有深入研究架构，但我想知道它是否会影响非监视节点/目录/文件/路径上的操作？
同样，它有什么不同fanotify？
答案1
我不使用inotifywatch，我使用gidget，所以我的答案不是特定于该工具的，这只是一个关于inotify的希望有用的观察（我重重地使用）。
每个 inotify 监视在 32 位架构上使用 540 字节的内核内存，在 64 位架构上使用 1080 字节。内核内存是不可交换的。所以肯定存在内存成本。
但根据我的经验，减慢速度的并不是监视的数量 - 内核会快速检查它们。在实际使用中，最容易影响系统性能的是 inotify 事件触发时您所做的任何事情。例如，如果您有十到四万个符合 HIPAA 标准的 835 文件通过千兆位或十千兆位链路以线速到达，则启动处理每个文件的用户进程将比 inotify 本身对系统造成更大的影响。
不过，至少要回答您的一个问题：不，设置监视不会对未监视的文件或文件夹产生任何影响/成本。内核总是检查是否有监视集，只要没有监视集，检查就会花费相同的时间和资源，无论有多少其他文件系统对象正在被监视。但同样，如果您不断生成大量进程（出于任何原因），这肯定会对整个系统性能产生影响。
另外，您提到您正在使用的工具可以递归地监视文件夹和子文件夹。这不是 inotify 所做的事情，而是您的工具正在做的事情。它可能会扫描您指定的子文件夹的文件夹，在所有文件夹上设置监视，然后在创建新监视时触发以设置另一个监视。因此，您会进行一些与 inotify 系统仅间接相关的开销活动，并且它对性能的影响将主要归因于该工具的行为而不是 inotify 的行为。如果该工具很草率并且资源效率低下（我不知道，但我有点怀疑，因为 inotify 工具通常是用 C 编写的），这可能是一个问题。