Linux inotify处理目录监控事件丢失风险的实现方法

Linux inotify 适合做目录变化的低延迟通知，但它不是一份永不丢失的事件日志。要处理“监控偶尔少文件”的风险，核心不是只把 max_queued_events 调大，而是把 IN_Q_OVERFLOW 当成缓存失真的明确信号：暂停增量更新，重新扫描受影响目录，必要时重建子目录 watch，再恢复正常读取。

先分清 watch、事件队列和业务缓存

调用 inotify_add_watch 得到的是 watch descriptor，也就是事件里的 wd。它只告诉程序“哪个被监控对象发生了什么”，并不保存目录的完整快照。程序通常还会维护一张 wd -> 路径 映射，再把事件合并到自己的索引、任务表或缓存中。

因此，事件处理器应该允许“通知只用于触发校准”。正常事件可以做增量更新；一旦发现队列溢出或 watch 映射失效，就切换到扫描结果作为新的基准。

最小实现：把队列溢出转成一次重扫信号

读取缓冲区中的每个 inotify_event 时，先判断 mask 是否带有 IN_Q_OVERFLOW。这个事件的 wd 为负值，不能再按普通文件事件拼路径。实际项目可以只标记一个原子状态，由独立恢复逻辑合并多次告警，避免并发触发大量重扫。

/* 这是处理思路示意，不代表本机运行输出。 */
static bool rescan_requested;

static void consume_events(int fd) {
    char buffer[64 * 1024];
    ssize_t n;

    for (;;) {
        /* 一次 read 可以带回多个事件，必须按 len 逐条移动指针。 */
        n = read(fd, buffer, sizeof(buffer));
        if (n mask & IN_Q_OVERFLOW) {
                /* 队列已溢出：不要猜测丢失的文件名，转入重扫。 */
                rescan_requested = true;
            } else {
                /* 普通事件只做增量更新，wd 需通过映射表解析路径。 */
                apply_incremental_change(event);
            }
            p += sizeof(*event) + event->len;
        }
    }
}

static void recover_if_needed(const char *root) {
    if (!rescan_requested) return;

    /* 先暂停依赖旧缓存的增量动作，再以目录扫描结果重建状态。 */
    pause_incremental_updates();
    rebuild_cache_from_scan(root);
    rebuild_missing_directory_watches(root);
    rescan_requested = false;
    resume_incremental_updates();
}

这里的关键点有两个：一是不能把扩大队列当作“不会丢”的证明；二是重扫必须是幂等的。恢复期间如果又收到普通事件，可以暂存为“需要再次校准”的标志，或者在恢复结束后再扫一次，不能直接假设旧事件仍完整。

重扫不是补读队列：四个边界要提前处理

1. 递归窗口：新目录出现后，添加 watch 与扫描其现有内容之间存在窗口，所以加 watch 后要立即扫描该目录。
2. 重命名：IN_MOVED_FROM 和 IN_MOVED_TO 可用 cookie 关联，但跨目录、并发写入和延迟读取都可能让配对变复杂；重扫应能纠正最终状态。
3. 删除与复用：目录删除会带来 IN_IGNORED，缓存中的 wd 不能永久当作路径身份，必须及时移除映射。
4. 文件系统范围：网络文件系统和部分伪文件系统不适合直接依赖 inotify；这类场景应准备轮询或其他采集方式。

参数配置和复查清单

max_queued_events 影响每个 inotify 实例的队列上限，max_user_watches 影响一个用户可建立的 watch 数量。它们是容量参数，不是一致性保证。复查时至少记录溢出次数、当前 watch 数量、最近一次重扫耗时和重扫后发现的新增/删除数量。

# 只读取当前内核参数，先确认容量，再决定是否调整配置
cat /proc/sys/fs/inotify/max_queued_events
cat /proc/sys/fs/inotify/max_user_watches

# 观察进程的 watch descriptor 数量，fd 号需替换为实际值
grep -c '^inotify' /proc/$$/fdinfo/* 2>/dev/null

如果溢出频繁出现，先减少不需要的事件类型、缩小监控范围并提升读取及时性；只有确认容量确实不足时再调整参数。最终目标是：事件用于快速发现变化，扫描用于恢复可信状态。

相关问题

把 max_queued_events 调大后还需要重扫吗？

需要。更大的队列只能降低溢出概率，不能消除突发写入、进程调度延迟和逻辑竞态。只要代码支持 IN_Q_OVERFLOW，就应该保留重扫路径。

为什么新增子目录后仍会漏文件？

目录监控本身不递归。新子目录从创建到成功加入 watch 之间可能已经写入文件，因此添加 watch 后要立刻扫描其内容，并递归处理更深层目录。

重扫时要不要关闭 inotify fd？

不一定。局部重扫可以保留 fd；如果队列已经失去可信度、watch 映射也难以修复，关闭 fd、清空缓存、重新建立实例和 watches 是更清晰但成本更高的全量恢复方案。