[转帖]Linux fuse用户态文件系统及其libfuse

转载

jinanxiaolaohu6 2024-01-16 12:13:25

文章标签 文件系统用户态 API 文章分类 Python 后端开发

为什么要有用户态文件系统

VFS文件系统可知文件系统在内核态的，应用程序操作文件，统一调用内核态的VFS层抽象接口。

突然有一天有一个和文件系统有关的需求，要编写一个特定功能的文件系统，不管是代码编写还是调试都不太方便，就算是仅仅在现有传统文件系统上添加一个小小的功能，在内核中实现仍需要做很大的工作量。

怎么解决这个问题呢？既然内核态开发和调试都不方便且耗费工作量，能不能在用户态实现一个易维护易调试的文件系统呢？

FUSE (Filesystem in Userspace) 用户态文件系统应运而生，不像其他内核态文件系统，编写FUSE文件系统时，只需要内核加载fuse模块，不需要重新编译内核。

FAQ：内核态文件系统如何开发新功能呢？如何繁琐如何不易调试？

什么是用户态文件系统fuse

用户态文件系统指一个文件系统的data和metadata都是由用户态的进程提供的（这种进程被称为"daemon"）。

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

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

[转帖]Linux fuse用户态文件系统及其libfuse_API

红框的部分是FUSE用户态文件系统的具体实现，也是用户态文件系统的设计者可以发挥的空间。

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

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

fuse包括fuse内核模块和libfuse用户态lib库两部分，libfuse提供接口和fuse内核模块通信。libfuse provides functions to mount the file system, unmount it, read requests from the kernel, and send responses back. libfuse offers two APIs: a "high-level", synchronous API(同步), and a "low-level" asynchronous API(异步). In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be sent explicitly using a separate set of API functions.

采用本地挂载的方式（假设本机的"dir-src"目录位于ext4文件系统）：sshfs localhost:<dir-src> <dir-dst>

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

[转帖]Linux fuse用户态文件系统及其libfuse_用户态_02