想象两个进程，一个读取器和一个写入器，通过 ext3 fs 上的常规文件进行通信。ReaderIN_MODIFY对文件有一个 inotify监视。Writer 在一次write()调用中将 1000 个字节写入文件。Reader 获取 inotify 事件，并调用fstat文件。读者看到了什么？
是否有任何保证 Reader 将至少获得 1000 美元st_size的文件？从我的实验来看，似乎不是。
有没有保证 Reader 实际上可以read()1000 个字节？
这发生在严重的 I/O 绑定框上。例如，sar显示大约 1 秒的等待时间。在我的情况下，Reader 在调用之前获得 inotify 事件后实际上等待了 10 秒stat，并且得到的结果太小。
我曾希望在文件准备好之前不会传递 inotify 事件。我怀疑实际发生的是 inotify 事件write()在 Writer 中的调用期间触发，并且只要数据准备就绪，系统上的其他进程实际上都可以使用该数据。在这种情况下，10 秒是不够的。
我想我只是想确认内核实际上按照我猜测的方式实现了 inotify。另外，如果有任何选择，可能会改变这种行为？
最后-考虑到这种行为，inotify 的意义何在？无论如何，在您获得事件后，您将不得不轮询文件/目录，直到数据实际可用为止。不妨一直这样做，而忘记 inotify。
*** 编辑 ** * * 好吧，正如经常发生的那样，我看到的行为实际上是有道理的，现在我明白了我真正在做什么。^_^
我实际上是在响应文件所在目录上的 IN_CREATE 事件。所以我实际上是在 stat()'ing 文件以响应文件的创建，不一定是 IN_MODIFY 事件，它可能稍后到达。
我将更改我的代码，以便在收到 IN_CREATE 事件后，我将订阅文件本身的 IN_MODIFY，并且在收到 IN_MODIFY 事件之前我不会实际尝试读取文件。我意识到那里有一个小窗口，我可能会错过对文件的写入，但这对我的应用程序来说是可以接受的，因为在最坏的情况下，文件将在最大秒数后关闭。