Inotify 是文件系统事件监控机制，计划包含在即将发布的 Linux 内核中作为 dnotify 的有效替代。dnotify 是较早内核支持的文件监控机制。Inotify 是一种强大的、细粒度的、异步的机制，它满足各种各样的文件监控需要，不仅限于安全和性能。下面让我们一起学习如何安装 inotify 和如何构建一个示例用户空间应用程序来响应文件系统事件。
文件系统事件监控对于从文件管理器到安全工具的各种程序都是必要的，但是 dnotify（早期内核中的标准）存在一些局限性，这使我们期待出现一种更加完善的机制。抱着这种期待，我们发现了 inotify，一种更加现代化的文件系统事件监控替代品。
为什么使用 inotify？
使用 inotify 取代 dnotify 的原因有很多。第一个原因是，dnotify 需要您为每个打算监控是否发生改变的目录打开一个文件描述符。当同时监控多个目录时，这会消耗大量的资源，因为有可能达到每个进程的文件描述符限制。
除此之外，文件描述符会锁定目录，不允许卸载（unmount）支持的设备，这在存在可移动介质的环境中会引发问题。在使用 inotify 时，如果正在监控被卸载的文件系统上的文件，那么监控会被自动移除并且您会接收到一个卸载事件。
dnotify 不如 inotify 的第二个原因是 dnotify 有点复杂。注意，使用 dnotify 基础设施的简单文件系统监控粒度只停留于目录级别。为了使用 dnotify 进行更细粒度的监控，应用程序编程人员必须为每个受监控的目录保留一个 stat 结构的缓存。该用户空间的 stat 结构缓存需要用来明确确定当接收到通知信号时目录发生了什么变化。当获得通知信号时，生成 stat 结构列表并与最新的状态相比较。显而易见，这种技术是不理想的。
inotify 的另一个优点是它使用文件描述符作为基本接口，使应用程序开发者使用 select 和 poll 来监控设备。这允许有效的多路 I/O 和与 Glib 的 mainloop 的集成。相反，dnotify 所使用的信号常常使程序员头疼并且感觉不太优雅。
inotify 通过提供一个更优雅的 API 解决了这些问题，该 API 使用最少的文件描述符，并确保更细粒度的监控。与 inotify 的通信是通过设备节点提供的。基于以上原因，对于监控 Linux 2.6 平台上的文件，inotify 是您最明智的选择。
安装 inotify
安装 inotify 的第一步是确定您使用的 Linux 内核是否支持它。检查发行版的最简单方法是，寻找是否存在 /dev/inotify 设备。如果存在该设备，您可以跳到 在简单应用程序中使用 inotify 一节。
在撰写本文时，inotify 包含在 Andrew Morton 的 Linux 2.6-mm 目录树中，而且一些 Linux 发行版正在提供支持 inotify 的内核（包括 Gentoo 和 Ubuntu）或者具有提供支持的补充内核包（例如 Fedora 和 SuSE）。因为 Andrew 可能会根据需要从目录树删除对 inotify 的支持，并且 inotify 版本还处于频繁的开发阶段，所以强烈建议您从头开始打补丁。
如果缺少该设备，您可能需要对内核打补丁并创建该设备。
为 inotify 对内核打补丁
可以从 Linux Kernel Archives 获得 inotify 补丁。您应该为特定的内核应用最高版本编号的补丁。每个发行版处理内核的安装都有所不同，但以下介绍的是一个通用指导。注意：从 Linux Kernel Archives 获取发行版 2.6 Linux 内核源文件，如果合适，请获取最新的稳定版本。
从进入内核源文件目录开始：
|
因为您早先安装了内核源文件，现在需要将它解压缩：
|
现在，使您的 symlink 指向新的源文件目录树：
|
改变当前目录到刚才创建的内核源文件目录：
|
拷贝 inotify 补丁：
|
将内核打补丁：
|
构建内核：
|
像平时一样配置您的内核，确保 inotify 工作正常。如果必要，请将新内核添加到引导加载程序中，但是一定要记住维护旧内核的映像和引导加载程序选项。这一步对于不同引导加载程序有所不同（请参阅 参考资料 了解关于特定引导加载程序的更多信息）。重新引导计算机并选择启用 inotify 的新内核。在继续往下操作前，测试您的新内核以确保它工作正常。
[1] [2] [3] [4] 下一页