Fuse性能优化介绍(解读)

Fuse即file system in user， 此文件系统是为了方便开发者修改文件系统时不需要再修改kernel，仅在用户空间修改就可以达到目的，因此将控制逻辑放到了用户空间。但是因为存在用户态和内核态的切换，所以Fuse的整体性能远不如其他基础文件系统，因而优化Fuse文件系统的性能成为一个关注点，尤其是在读写大文件或者发生随机访问的时候，更是体现了Fuse性能差的毛病。本文旨在解读已有的优化措施。

优化措施参考以下网站：

https://patchwork.kernel.org/project/linux-fsdevel/list/?series=370423
https://review.lineageos.org/c/LineageOS/android_kernel_samsung_jf/+/100347

背景：
首先来介绍下该优化措施的背景，前文说到在使用Fuse读写大文件或者随机读写的时候，因为会涉及到频繁的内核态与用户态之间的切换，所以会消耗大量的系统资源，进行使读写速率降低，而其他的IO操作一般只有一次，不会像读写这样很频繁的切换，所以关键在于解决读写(尤其是随机读写)的性能瓶颈。

优化解读：
启用了该优化措施后，读写过程都将通过VFS把请求传递到和Fuse相关的更低一级文件系统(lower file system)，不再是Fuse文件系统将数据切换到用户空间，在用户空间的守护进程通过更低级别的文件系统进行读写。即原本内核态和用户态的切换过程就不存在了，直接在内核态运行，进而达到性能优化的目标。这样的说法有点抽象，接下来通过一个read的过程来说明该方法。

这是一个标准的向文件注入内容的过程
1、用户进程通过open打开或者创建一个文件；
2、使用read函数通过返回的文件描述符向文件注入内容；
3、使用close函数关闭文件；

在Fuse文件系统中，open调用后，VFS会先访问Fuse，然后Fuse将请求发送给注册到对应设备节点的进程中，该进程会有一系列的逻辑控制(AndroidR中是MediaProvider进程)，最后再次访问更低一层的文件系统，直到访问到基础文件系统，返回一个文件描述符；当read执行到VFS后，继续执行相同的流程，close也是一样。如果在open和close之间有n词read的过程，那就至少有6n此用户态和内核态之间的切换，总计就有6(n+2)次切换过程。

当启动该优化措施后，原本的open流程基本不变，只是在返回文件描述符的时候做一份拷贝保存在Fuse的文件系统中，接下来执行read的时候不再切到用户态去读取数据，而是通过保存的文件描述符使Fuse直接与更低一级别的文件系统建立联系，进而直接从低级别文件系统读取数据；close仍然与原来的流程一样，只是在期间将保存的文件描述符等释放掉，保证不浪费内存。这样一来假设还是执行n次read，内核态与用户态切换的次数只有6 * 2 + 2 * n，大约相较原来节约三分之二的时间。这样就大大提高了读写的性能，实际也确实如此，在读写上相较之前有很大的提升。

最后来看下对应的修改(前提是你已经比较了解Fuse的内核源码，否则建议先熟悉下Fuse的源码流程)：

static int fuse_send_open(struct fuse_conn *fc, u64 nodeid, struct file *file,
			  int opcode, struct fuse_open_out *outargp,
			  struct file **lower_file)
{
   
	struct fuse_open_in inarg;
	struct fuse_req *req;
	int err;

	req = fuse_get_req(fc);
	if (IS_ERR(req))
		return PTR_ERR(req);

	memset(&inarg, 0, sizeof(inarg));
	inarg.flags = file->f_flags & ~(O_CREAT | O_EXCL | O_NOCTTY);
	if (!fc