用户态文件系统 - FUSE（用户态文件系统有哪几种）

所谓“用户态文件系统”，是指一个文件系统的data和metadata都是由用户态的进程提供的（这种进程被称为"daemon"）对于micro-kernel的操作系统来说，在用户态实现文件系统不算什么，但对于macro-kernel的Linux来说，意义就有所不同。

虽然叫做用户态文件系统，但不代表其完全不需要内核的参与，因为在Linux中，对文件的访问都是统一通过VFS层提供的内核接口进行的（比如open/read），因此当一个进程（称为"user"）访问由daemon实现的文件系统时，依然需要途径VFS。

当VFS接到user进程对文件的访问请求，并且判断出该文件是属于某个用户态文件系统（根据mount type），就会将这个请求转交给一个名为"fuse"的内核模块而后，"fuse"将该请求转换为和daemon之间约定的协议格式，传送给daemon进程。

图 1可见，在这个三方关系中，"fuse"这个内核模块起的是一个转接的作用，它帮助建立了VFS（也可以说是user进程）和daemon之间的交流通道，通俗点说，它的角色其实就是一个「代理」这一整套框架的实现在Linux中即为。

FUSE (Filesystem in Userspace)如图1所示，红框的部分才是FUSE类型文件系统的具体实现，才是用户态文件系统的设计者可以发挥的空间目前，已有不下百种基于FUSE实现的文件系统（一些基于内核的文件系统也可以porting成用户态文件系统，比如ZFS和NTFS），而本文将选用一个现成的。

fuse-sshfs来进行演示首先安装fuse-sshfs的软件包，使用如下的命令进行文件系统的mount（将远端机器的"remote-dir"目录挂载到本机的"local-dir"目录）：sshfs : 。

之后，在"/sys/fs"目录下，将生成一个名为"fuse"的文件夹，同时可以看到"fuse"内核模块已被加载（其对应的设备为"/dev/fuse"），并且本机的挂载目录的类型已成为"fuse.sshfs"：

生成设备节点的目的是方便用户态的控制，但是对于文件系统这种级别的应用来说，直接使用 ioctl() 来访问设备还是显得麻烦，因为呈现了太多的细节，所以libfuse作为一个中间层应运而生，daemon进程实际都是通过libfuse提供的接口来操作fuse设备文件的。

你来我往接下来，以在"fuse.sshfs"文件系统中通过"touch"命令新建一个文件为例，查看fuse内核模块和daemon进程（即"sshfs"）具体的交互流程（代码部分基于内核5.2.0版本）：

【第一轮】最开始是permission的校验，不过这里的校验并不等同于VFS的权限校验，它的主要目的是为了避免其他user访问到了自己私有的fuse文件系统。

然后就是根据文件路径查找文件的inode。由于是新建的文件，inode并不在内核的inode cache中，所以需要向daemon发送"lookup"的请求：

这些请求会被放入一个pending queue中，等待daemon进程的回复，而user进程将陷入睡眠：

作为daemon，sshfs进程通过读取"/dev/fuse"设备文件来获得数据，如果pending queue为空，它将陷入阻塞等待：

当pending queue上有请求到来时，daemon进程将被唤醒并处理这些请求被处理的请求会被移入processing queue，待daemon进程向fuse内核模块做出reply之后，user进程将被唤醒，对应的request将从processing queue移除。

【第二轮】接下来就是执行"touch"命令时所触发的其他系统调用，如果是之前访问过的data/metadata，那很可能存在于cache中，再次访问这部分data/metadata的时候，fuse内核模块就可以自行解决，不需要去用户空间往返一趟，否则还是需要上报daemon进程进行处理。

这里 get_fuse_conn() 获取的是在fuse类型的文件系统被mount时创建的"fuse_conn"结构体实例作为daemon进程和kernel联系的纽带，除非daemon进程消亡，或者对应的fuse文件系统被卸载，否则该connection将一直存在。

在daemon进程这一端，还是类似的操作需要注意的是区别 fuse_write/read() 和fuse_dev_write/read() 这两个系列的函数，前者是user进程在访问fuse文件系统上的文件时的VFS读写请求，属于对常规文件的操作，而后者是daemon进程对"/dev/fuse"这个代表fuse内核模块的设备的读写，目的是为了获取request和给出reply。

【第三轮】fuse内核模块和daemon进程的最后一轮交互是在代表fuse文件系统的superblock中获取inode号，并填写这个metadata的相关信息。

硬币的两面不难发现，在fuse文件系统中，即便执行一个相对简单的"touch"操作，所涉及的用户态和内核态的切换都是比较频繁的，并且还伴随着多次的数据拷贝相比于传统的内核文件系统，它整体的I/O吞吐量更低，而延迟也更大。

那为什么fuse在操作系统支持的文件系统里面依然占据一席之地呢？说起来，在用户态开发是有很多优势的一是便于调试，特别适合做一个新型文件系统prototype的快速验证，因此在学术研究领域颇受青睐在内核里面，你只能用C语言吧，到了用户态，就没那么多限制了，各种函数库，各种编程语言，都可以上。

二是内核的bug往往一言不合就导致整个系统crash（在虚拟化的应用中更为严重，因为宿主机的crash会导致其上面运行的所有虚拟机crash），而用户态的bug所造成的影响相对有限一些所以，硬币的正面是便于开发，不过到底有多方便，这毕竟是一种。

主观的感受，而反面则是性能的影响，这可是能够用客观的实验数据来验证的那应该用什么方法才能相对准确地衡量fuse所带来的损耗呢？还是用前面用过的这个fuse-sshfs，不过这里我们不再使用远端挂载，而是采用本地挂载的方式（假设本机的"dir-src"目录位于ext4文件系统）：。

sshfs localhost: 当daemon进程收到请求后，它需要再次进入内核，去访问ext4的内核模块（这种文件系统模式被称为"stackable"的）：

以user进程向fuse文件系统发出 write() 请求为例，右边红框部分是一次原生的ext4调用路径，而左边多出来的就是因为引入fuse后增加的路径：

根据这篇文档给出的数据，在这一系统调用中使用到的"getxattr"所形成的request，需要2倍的"user-kernel"交互量对于顺序写，相比起原生的ext4文件系统，I/O吞吐量降低27%，随机写则降低44%。

不过，在fuse文件系统诞生的这么多年里，大家还是为它想出了很多的优化举措比如，顺序读写的时候，可以设计为向daemon进程批量发送request的形式（但随机读写不适合）还有就是使用splicing这种zero-copy技术，由Linux内核提供的splicing机制允许用户空间在转移两个内核的内存buffer的数据时，不需要拷贝，因此尤其适合stackable模式下，从fuse内核模块直接向ext4内核模块传递数据（但splicing通常用于超过4K的请求，小数据量的读写用不上）。

经过这些努力，fuse文件系统的性能可以达到什么样的一种程度呢？根据这篇报告列出的测试结果，相比起原生的ext4，在最理想的情况下，fuse的性能损耗可以控制到5%以内，但最差的情况则是83%同时，其对CPU的资源占用也增加了31%。

从Android v4.4到v7.0之间存在的sdcard daemon，到最近几年的Ceph和GlusterFS，都曾经采用过或正在采用基于FUSE的实现FUSE在network filesystem和虚拟化应用中都展现了自己的用武之地，它的出现和发展，并不是要取代在内核态实现的文件系统，而是作为一个有益的补充（理论上，FUSE还可以用于实现根文件系统，但是不建议这么做，"can do"和"should do"是两回事）。

原创文章，转载请注明出处。