為了遞歸地觀看我的主目錄和所有子目錄 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 編寫的），這可能是一個問題。