watch_mount(), watch_sb(), and fsinfo() (again)

关注

转载最新推荐文章于 2026-08-13 15:50:43 发布 404 阅读 AI 写同款· GEO 优化 ›

Linux 进程间通信 pipe 实现原理本文基于 Linux-5.10 版本分析，借助 pipe 分析等待队列，为了下篇文章分析 slect/poll/epoll 实现做准备。pipe 是 Linux 系统中一种比较常用的进程间通信方法，不过使用 pipe 通信的两个进行必须有亲属关系，通常是父子进程。pipe 和 pipe2 返回成功时，pipefd 保存两个文件描述符：pipefd[0] 用于读，pipefd[1] 用于写。阅读详情

关注了就能看到更多这么棒的文章哦～

watch_mount(), watch_sb(), and fsinfo() (again)

By Jonathan Corbet
February 24, 2020

原文来自：https://lwn.net/Articles/813172/

filesystem的设计目标就是为了减少用户使用时的复杂性。不过，有些时候用户确实希望能看到这个黑盒内部，了解文件系统内部做了些什么事情。David Howells曾经创建了不少针对filesystem的系统调用，为了这个需求，又做了一组patch set增加了3个新的system call。其中1个系统调用我们之前就看到过，另外两个则是全新的。这两个新的系统调用是watch_mount和watch_sb()，它们供进程调用来注册申请，今后在mount point（挂载点）或者是在某个特定的已经mount好的文件系统内部（watch_sb里面的sb指的是superblock）发生变化的时候，这个进程就能收到通知。mount point发生变化，包含在mount point之下mount或者unmount某个文件系统，也包括属性变化，例如read-only、改变挂载点等等。文件系统相关的event也包含一些属性变化，还包括文件系统报错、quota配额问题、远程文件系统的网络问题等。

这些系统调用都是基于Howells近来一直在改善的一个event-notification机制的最新版本的。此前，要想能获取通知，需要先打开一个/dev/watch_queue设备，不过这个接口已经变了。最新版本里面，进程需要调用pipe2()，传入新增的O_NOTIFICATION_PIPE flag，来创建一种特殊的pipe，专用于notification。这个pipe（管道）的写入端不是供application使用的。而pipe的reader端的文件描述符则会传递给下面这两个新增的system call：

    int watch_mount(int dirfd, const char *path, unsigned int flags,
    		    int watch_fd, int watch_id);
    int watch_sb(int dirfd, const char *path, unsigned int flags,
    		 int watch_fd, int watch_id);

在这两种调用中下，dirfd、path和flags都是用来指明所关心的目录的，就跟通常openat()的参数一样。watch_fd则是notification pipe，watch_id则是一个整数值，在所有event里面都会附带返回出来。不过还有个特殊情况，如果watch_id是-1，那么就把现存的监测给删除掉。

应用程序只要对这个管道进行read操作，就可以收到event了。缺省会把所有会影响到这个watch point的event都返回出来。不过应用程序也可以对这个notification pipe进行ioctl()来创建一个filter进行过滤。此外还有一个ioctl()可以来设置容纳这些发给user space的notification的buffer有多大。感兴趣的读者可以看看这个示例程序来了解如何使用这些系统调用 https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tree/samples/watch_queue/watch_test.c?h=fsinfo-core

fsinfo()则是一个此前就提出来过的一个系统调用。它的原型都没有变：

    int fsinfo(int dirfd, const char *path, const struct fsinfo_params *params,
	       void *buffer, size_t buf_size);

参数也没有变过，dirfd和path是用来指定要索取信息的文件系统的。这里没有flags参数了，而是藏在params这个结构中，详情如下：

    struct fsinfo_params {
	__u32	at_flags;
	__u32	flags;
	__u32	request;
	__u32	Nth;
	__u32	Mth;
	__u64	__reserved[3];
    };

这里的at_flags放的就是人们通常在openat()这类系统调用中常用的flags参数。request则指定它在索取什么样的信息，从这个patch里面可以看到它可能的取值范围。可能可以提供的信息（这里说“可能”，是因为有些文件系统其实并没有提供这些信息）包括filesystem limits，timestamp resolution information, volume（卷） UUID, 具体连接到的远程系统的服务器是哪个，等等等等。有些属性可以取多个值，就可以用Nth和Mth这两项来指定是哪个。返回信息的格式其实挺复杂的，数值都是写在上面提供的buffer里的，格式则有好多种可能，取决于申请的目标信息。有些情况下，会返回一个structure，其他一些情况则会返回string或者一个名为“opaque”的类型。patch里面有一些介绍，不过很显然使用这个系统调用的人可能需要自己深入钻研一下，具体返回给他们的数据是什么格式。

这组patch set已经是第17版了，已经演化很久了。目前针对这组patch的唯一评论是来自James Bottomley的，他认为这个fsinfo()系统调用是不是其实并不需要。而是应该修改一下fsconfig()（这是用来配置filesystem attribute的API）的实现方式，能让它变成一个可以set attribute也可以read attribute的接口。目前来说，Howells还没回复。

这组patch已经走到第17版了，这已经能说明很多东西了。大家都赞同，有时候确实需要能从kernel获取一些信息出来，不过这个API还是有点太复杂了，用户比较难于理解。不知道最终是否能够既实现这些功能又能解决这个问题。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～