Go 存储基础 — “文件”被偷偷修改?来,给它装个监控!

背景

我们总有这样的担忧:总有刁民想害朕,总有人偷偷在目录下删改文件,高危操作想第一时间了解到,怎么办?

通常我们还有这样的需求:

  • 监听一个目录中所有文件,文件大小到一定阀值,则处理;
  • 监控某个目录,当有文件新增,立马处理;
  • 监控某个目录或文件,当有文件被修改或者删除,立马能感知,进行处理;

怎么做到这个事情呢?最常见的通常有三个办法:

  1. 第一种:当事人主动通知你,这是侵入式的,需要当事人修改这部分代码来支持,依赖于当事人的自觉;
  2. 第二种: 轮询观察,这个是无侵入式的,你可以自己写个轮询程序,每隔一段时间唤醒一次,对文件和目录做各种判断,从而得到这个目录的变化;
  3. 第三种:操作系统支持,以事件的方式通知到订阅这个事件的用户,达到及时处理的目的;

很明显,第三种最好:

  1. 纯旁路的逻辑,对线上程序无侵入;
  2. 操作系统直接支持,以事件的形式通知,性能也最好,100% 准确率(比较自己轮询判断要好);

怎么做到这个事情呢?

既然是操作系统的支持,那么就涉及到系统调用。系统调用直接使用略微复杂了些,Go 里面有个库 fsnotify ,就是封装了系统调用,用来监控文件事件的。当指定目录或者文件,发生了创建,删除,修改,重命名的事件,里面就能得到通知。

Go 的 fsnotify 的使用

使用方法非常简单:

  1. 先用 fsnotify 创建一个监听器;
  2. 然后放到一个单独的 Goroutine 监听事件即可,通过 channel 的方式传递;
package main

import (
    "log"
    "github.com/fsnotify/fsnotify"
)

func main() {
    // 创建文件/目录监听器
    watcher, err := fsnotify.NewWatcher()
    if err != nil {
        log.Fatal(err)
    }
    defer watcher.Close()
    done := make(chan bool)
    go func() {
        for {
            select {
            case event, ok := <-watcher.Events:
                if !ok {
                    return
                }
                // 打印监听事件
                log.Println("event:", event)
            case _, ok := <-watcher.Errors:
                if !ok {
                    return
                }
            }
        }
    }()
    // 监听当前目录
    err = watcher.Add("./")
    if err != nil {
        log.Fatal(err)
    }
    <-done
}

我们测试一下(有惊喜哦)。先把上述程序编译,然后跑起来:

root@ubuntu:~/code/gopher/src/notify# ./notify 

再打开一个终端,准备进行你的操作:

touch 一个新文件 hello.txt

touch hello.txt

使用 vim 打开这个文件,写入一行数据,然后关闭退出:

vim hello.txt
root@ubuntu:~/code/gopher/src/notify# ./notify 
# 触发事件:创建的时候
2021/08/20 17:02:52 event: "./hello.txt": CREATE
2021/08/20 17:02:52 event: "./hello.txt": CHMOD
# 触发事件:vim 打开初始化的时候(创建 swp 文件)
2021/08/20 17:17:08 event: "./.hello.txt.swp": CREATE
2021/08/20 17:17:08 event: "./.hello.txt.swx": REMOVE
2021/08/20 17:17:08 event: "./.hello.txt.swp": REMOVE
2021/08/20 17:17:08 event: "./.hello.txt.swp": CREATE
2021/08/20 17:17:08 event: "./.hello.txt.swp": WRITE
2021/08/20 17:17:08 event: "./.hello.txt.swp": CHMOD
# 触发事件::w 写入保存的时候
2021/08/20 17:17:53 event: "./4913": REMOVE
2021/08/20 17:17:53 event: "./hello.txt": RENAME
2021/08/20 17:17:53 event: "./hello.txt~": CREATE
2021/08/20 17:17:53 event: "./hello.txt": CREATE
2021/08/20 17:17:53 event: "./hello.txt": WRITE
2021/08/20 17:17:53 event: "./hello.txt": CHMOD
2021/08/20 17:17:53 event: "./hello.txt": CHMOD
2021/08/20 17:17:53 event: "./hello.txt~": REMOVE
# 触发事件::q 的退出时候
2021/08/20 17:17:57 event: "./.hello.txt.swp": WRITE
2021/08/20 17:18:11 event: "./.hello.txt.swp": REMOVE

惊喜就是,这里能和之前 vim 的分享篇能结合上:

  1. 看到了 ~ 镜像文件,还看到了 swp 文件,竟然还看到了 一个 4913 的文件(这个文件也是个临时文件,感兴趣的可以查一下);

太神奇了,这样你就有一个新的手段监控你的文件发生的任何事情了。这是什么原理呢?

深层原理

fsnotify 是跨平台的实现,奇伢这里只讲 Linux 平台的实现机制。fsnotify 本质上就是对系统能力的一个浅层封装,主要封装了操作系统提供的两个机制:

  1. inotify 机制;
  2. epoll 机制;

旁白:真的是何处都有 epoll 呀。如果还有对 epoll 不明白的赶紧复习下 Linux fd 系列,epoll 剖析。

环境声明

Linux 内核版本 4.19

inotify

什么是 inotify 机制?

这是一个内核用于通知用户空间程序文件系统变化的机制。

划重点:其实 inotify 机制的诞生源于一个通用的需求,由于IO/硬件管理都在内核,但用户态是有获悉内核事件的强烈需求,比如磁盘的热插拔,文件的增删改。这里就诞生了三个异曲同工的机制:hotplug 机制、udev 管理机制、inotify 机制。

inotify 的三个接口

操作系统提供了三个接口来支撑,非常简洁:

// fs/notify/inotify/inotify_user.c

// 创建 notify fd
inotify_init1

// 添加监控路径
inotify_add_watch

// 删除一个监控
inotify_rm_watch

用法非常简单,分别对应 inotify fd 的创建,监控的添加和删除。

inotify 怎么实现监控的?

inotify 支持监听的事件非常多,除了增删改,还有访问,移动,打开,关闭,设备卸载等等事件。

内核要上报这些文件 api 事件必然要采集这些事件。在哪一个内核层次采集的呢?

系统调用 -> vfs -> 具体文件系统( ext4 )-> 块层 -> scsi 层

**答案是:vfs 层。**其实这个很容易理解,这是必然的,因为这是所有“文件”操作的入口。

以 vfs 的 read/write 为例,我们看一下:

ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
    // ...
    ret = __vfs_read(file, buf, count, pos);
    if (ret > 0) {
        // 事件采集点:访问事件
        fsnotify_access(file);
    }

}

ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
{
    // ...
    ret = __vfs_write(file, buf, count, pos);
    if (ret > 0) {
        // 事件采集点:修改事件
        fsnotify_modify(file);
    }
}

fsnotify_accessfsnotify_modify 就是 inotify 机制的一员。有一系列 fsnotify_xxx 的函数,定义在 include/linux/fsnotify.h ,这函数里面全都调用到 fsnotify 这个函数。

static inline void fsnotify_modify(struct file *file)
{
    // 获取到 inode

    if (!(file->f_mode & FMODE_NONOTIFY)) {
        fsnotify_parent(path, NULL, mask);
        // 采集事件,通知到指定结构
        fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
    }
}

来看一下 fsnotify 的函数实现,我们简单的梳一下调用栈:

fsnotify
    -> send_to_group
        -> inotify_handle_event
            -> fsnotify_add_event
                -> wake_up (唤醒等待队列,也就是 epoll)

再看一眼具体的实现(其实非常简单,就是一个事件通知):

// 把事件通知到相应的 group 上;
int fsnotify(struct inode *to_tell, __u32 mask, const void *data, int data_is, const unsigned char *file_name, u32 cookie)
{
        // ...
        // 把事件通知给正在监听的 fsnotify_group
        while (fsnotify_iter_select_report_types(&iter_info)) {
                ret = send_to_group(to_tell, mask, data, data_is, cookie, file_name, &iter_info);
                if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
                        goto out;
                fsnotify_iter_next(&iter_info);
        }
out:
        return ret;
}

static int send_to_group(struct inode *to_tell, __u32 mask, const void *data, int data_is, u32 cookie, const unsigned char *file_name, struct fsnotify_iter_info *iter_info)
{
    // 通知相应的 group ,有事来了!
    return group->ops->handle_event(group, to_tell, mask, data, data_is, file_name, cookie, iter_info);
}

// group->ops->handle_event 被赋值为 inotify_handle_event

int inotify_handle_event(struct fsnotify_group *group, struct inode *inode, u32 mask, const void *data, int data_type, const unsigned char *file_name, u32 cookie, struct fsnotify_iter_info *iter_info)
{
    // 唤醒事件,通知相应的 group
    ret = fsnotify_add_event(group, fsn_event, inotify_merge);
}


// 添加事件到 group 
int fsnotify_add_event(struct fsnotify_group *group, struct fsnotify_event *event, int (*merge)(struct list_head *, struct fsnotify_event *))
{
    // 唤醒这个等待队列
    wake_up(&group->notification_waitq);
}

这里面的逻辑非常简单:把这次的事件通知给关注的 fsnotify_group 结构体,换句话说,就是把事件通知给 inotify fd。

这个就有意思了,inotify fd 句柄创建的时候,file->private_data 上就绑定了一个 fsnotify_group ,这就对上了。这样的话,针对文件的所有操作,都能有一份事件发送到 fsnotify_group 上,inotify fd 就有可读事件了。

inotify 也有支持 epoll 机制

在前面我们也提到了,Go 的 fsnotify 主要使用了两个系统机制 inotify 机制和 epoll 机制。fsnotify 把 inotify fd 放到 epoll 池里面管理。

换句话说,inotify fd 支持 epoll 机制。所以有最明显的两个特征:

  1. inotify fd 的 inotify_fops 实现了 .poll 接口;
  2. inotify fd 相关的某个结构体一定有个 wait 队列的表头

这个结构体是啥?

其实跟 timerfd 类似(读者有不熟悉的,可以去复习下哦),笔者直接揭秘啦,这个结构体就是 fsnotify_group 。被存放在 inotify fd 对应的 file->private_data 字段。这个 wait 队列表头就是 group->notification_waitq

来看一眼结构体的简要关系:

962c0fb6e9143dc2dd3dc405e4d87e59.png

epoll 机制

回到 Go 的 fsnotify 库的实现原理,fsnotify 利用的第二个系统机制就是 epoll 。inotify fd 通过 inotify_init1 创建出来之后,会把 inotify fd 注册进 epoll 管理,监听 inotify fd 的可读事件。

inotify fd 的可读事件能是啥?

就是它监听的文件或者路径发生的增删改的事件嘛,这些事件就是内核 inotify 报上来的。

报上来之后,epoll 监控到 inotify fd 可读,用户通过 read 调用,把 inotify fd 里面的“数据”读出来。这个读出来的所谓的“数据”就是一个个文件事件。

我们看一眼整体的模块层次:

538b99cc625fb178dc79ef0228f5a0a5.png

总结

  1. Go 的 fsnotify 库很方便对文件、目录做监控,这里的充满了想象力,因为一切皆文件,这代表着一切可监控。童鞋们,这里的想象空间非常大哦;
  2. 通过 fsnotify 我们映证了 vim 的秘密;
  3. Go 的 fsnotify 其实操作系统能力的浅层封装,Linux 本质就是对 inotify 机制;
  4. inotify 也是一个特殊句柄,属于匿名句柄之一,这个句柄用于文件的事件监控
  5. fsnotify 用 epoll 机制对 inotify fd 的可读事件进行监控,实现 IO 多路复用的事件通知机制;

后记

“总有刁民想害朕”,终于不怕文件被偷偷动手脚了,有了 fsnotify 之后,文件(目录)做的任何事情我总能第一时间感知到。

今天又学到一个新的 fd 类型呢,inotify fd,一个用于监控文件事件的机制,这个在一切皆文件的 Linux 中,尤为重要,因为这代表着一切可监控!!!这里面能做到的事情太多了。


坚持思考,方向比努力更重要。关注公众号:奇伢云存储,获取更多干货。 关注我公众号, 获取更多干货