Linux inotify 队列溢出后怎么恢复完整扫描

inotify 队列溢出后，正确做法不是根据剩下的事件“猜回”缺失文件，而是把当前缓存视为不可信：先标记需要恢复，再对被监控目录做一次全量扫描，重建缓存和目录监听。IN_Q_OVERFLOW 的 wd 为 -1，它只告诉你队列发生过丢弃，并不会携带丢失文件的清单。

事件合并不等于队列溢出

inotify 从文件描述符读出的是有序事件队列，但内核会把尚未读取且 wd、掩码、cookie、文件名都相同的连续事件合并。因此，“同一个文件写了三次”不一定得到三条完全相同的记录，这是正常的压缩行为，不代表文件状态丢失。

真正需要切换恢复模式的是 IN_Q_OVERFLOW。/proc/sys/fs/inotify/max_queued_events 为每个新建 inotify 实例设置队列上限；超过上限的事件会被丢弃，但会生成一个溢出事件。调大这个值只能降低再次溢出的概率，不能恢复已经丢掉的路径变化，而且修改后应让新的 inotify 实例读取新配置。

收到 IN_Q_OVERFLOW 后怎么恢复完整状态

恢复动作要有一个明确的“脏”状态。收到溢出事件后，不要继续把后续 IN_CREATE、IN_DELETE 当成完整增量；它们前面可能已经缺少对应的创建、删除或重命名事件。先暂停对外提供“已同步”的结论，再执行根目录扫描。

#include 

static int cache_dirty;

static void handle_event(const struct inotify_event *event) {
    /* 溢出意味着增量链断了，不能用剩余事件拼出完整差异。 */
    if (event->mask & IN_Q_OVERFLOW) {
        cache_dirty = 1;
        return;
    }

    /* 脏状态下只记录线索，真正的状态以全量扫描为准。 */
    if (cache_dirty)
        return;

    apply_incremental_change(event);
}

static void recover_tree(void) {
    /* 扫描目录并重建索引；扫描结束后再处理期间积累的事件。 */
    rebuild_cache_from_tree();
    rebuild_directory_watches();
    cache_dirty = 0;
}

上面的关键不是函数名，而是边界：cache_dirty 一旦置位，缓存只能由当前文件系统的扫描结果恢复。扫描时要考虑竞态：如果恢复期间再次收到 IN_Q_OVERFLOW，本轮结果仍不能宣布完成，应重新标记并再扫一轮。对重要索引，可以给每次恢复一个 generation，只有扫描结束后的复查没有新溢出，才发布新 generation。

递归目录监听要一起重建

inotify 对目录不是递归监听。新建子目录或把已有目录移入树中后，需要单独添加 watch；而添加 watch 前，子目录里可能已经出现文件，所以“加 watch”与“扫子目录”应视为一组动作。溢出恢复时，建议把根目录扫描、子目录 watch 映射和缓存索引当成一个整体重建。

如果旧 fd 上还留着难以解释的事件，可靠性优先的实现可以关闭 inotify fd、清空应用缓存、创建新的 inotify 实例，再重新添加 watches。这样也能避免旧的 watch descriptor 映射与新路径表混用。代价是扫描和重建会产生额外 IO，应把它做成可观测、可限流的后台恢复任务，而不是无条件频繁重启。

常见问题

把 max_queued_events 调大就不会丢事件了吗？

不能保证。它只是提高新实例的队列容量；生产程序仍必须处理 IN_Q_OVERFLOW，并准备全量重建路径。

能不能只扫描发生变化的目录？

如果你能证明溢出只影响某个隔离队列，可以局部恢复；否则最稳妥的是扫描整个被监控根目录，因为事件已经没有完整的路径集合。

为什么重建 watch 后还要再扫描？

目录监听不是递归的，新增目录在建立 watch 前可能已经有内容；再扫描能补上这段窗口，并帮助发现恢复期间的竞态。

结语

inotify 适合做低成本变化通知，不适合作为唯一的事实数据库。把 IN_Q_OVERFLOW 当作“增量链失效”信号，采用全量扫描、缓存重建、watch 重建和复查收敛，才能让文件索引从丢事件中恢复到可解释状态。事件结构、队列上限与限制可继续参考 inotify(7)。