基于Fuse的用户态文件系统性能优化几点建议 - 比思論壇

目前很多文件系统基于Fuse（ http://fuse.sourceforge.net/ ）开发，在较为深入钻研Fuse实现后，总结出开发此类文件系统时可考虑的优化方案，拿出来与大家讨论讨论，如有不准确的地方，还望大家不吝赐教。阅读本文前，我假设你对Fuse有了足够多的了解（起码知道Fuse有两个模块：Fuse Kernel 和LibFuse以及知道一个应用程序调用行为如何传递至我们自己开发的基于Fuse的文件系统），否则，请先移步。

Linux中每个打开文件在内核中拥有两种元数据信息：struct dentry和struct inode，它们是文件在内核的基础结构。所有对文件的操作，都需要先获取文件这两个结构方可继续下去，而这两个结构又是由具体文件系统负责构造填充。以下两点解释了元数据优化的必要性：

因为Fuse的内核模块只是一个桥梁，连接了应用程序和我们基于Fuse开发的文件系统。所以，按照道理说，每次获取文件/目录的inode以及dentry的时候Fuse内核模块都应该去LibFuse以及我们的文件系统走一遭。

但是这样做的话缺点非常明显：IO路径拉长，效率变低，而且假如我们基于fuse开发的文件系统是网络文件系统（例如NOS等），可能会导致后端服务器压力增大。

有鉴于此，Kernel Fuse模块中增加了元数据缓存，包含dentry和inode。相比本地文件系统，我们必须时刻警惕一个问题：缓存有效性。所以，如何在提升性能的同时又尽量保证正确性是一个棘手的问题。

利用fuse挂载我们自己文件系统时，可指定dentry以及inode属性有效时间，当然这个有效时间得具体问题具体设置了，无统一答案。

应用程序每次对基于Fuse开发的文件系统的文件写入必先经过Kernel Fuse模块，Kernel Fuse其实是有很大权限决定何时将数据写入到用户态文件系统的。写的越频繁，效率必然越低，但一致性可能会更好，控制写入频率其实也是一个权衡的过程。

稍微熟悉Kernel你可能就会知道内核的IO其实是以Page为单位的。内核会将应用程序的写入请求按照PAGE_SIZE划分成多个page，然后再对page进行IO，简洁优美。

如果不作优化，Kernel Fuse对应用程序的每次page都会调用一次用户态文件系统的写操作，这样假如我们用户态的64KB的写请求，按照默认的PAGE_SIZE（4KB）可能会触发16次的用户态写，实际IO次数被放大，效率严重下降。优化后Kernel Fuse默认会每128KB才触发一次用户态文件系统写调用，当然亦可指定触发写调用的阈值。

Linux文件系统实现充分利用了内存来缓存文件数据，这样应用程序很多时候读文件其实只需从内核缓冲区拷贝数据至用户态缓冲区即可，根本不必启动磁盘IO。

由于Fuse的特殊性，需要严格控制数据缓存行为（看看我们前面提到的元数据缓存吧），因为可能我们实现的基于Fuse的文件系统其实是一个网络文件系统，那么如果使用内核缓存，可能就读到脏数据，因为作为用户态的你是很难控制内核的行为的。

不过Fuse的作者非常周到，它提供了多种挂载选项，来控制缓存行为，但友情提醒：一旦选择开启缓存，请为自己的可能读的过期数据负责。

顺便提一句：我们上面说的都是参数kernel_cache的行为，没有说明auto_cache的行为，留给各位读者仔细研究吧，提个醒：该选项是基于文件修改时间进行内核缓存有效性检测的优化策略。

预读是在是一件有趣的事情。Linux内核通过预读改变了应用程序的原始读行为。比如应用程序发起了一个16KB的读请求，内核可能莫名其妙地读取64KB数据等。当然，它这么做肯定有其道理，简单来说：一切为了性能，为了性能的一切。另外，我会在近期推出一篇预读相关文章，详细阐述预读机制，敬请关注。

Fuse允许挂载用户态文件系统时指定预读窗口大小，Fuse会用该设定值作为最大的预读窗口大小，若不指定，会采用Linux默认的最大预读窗口大小128KB。但是其实如果你设置了Fuse的预读窗口超过Linux默认的128KB也是徒劳，因为VFS不允许预读窗口超过128KB限制，所以总的来说，优化的意义不大。

某些时候，应用程序希望绕过OS的缓存而自己管理缓存（如数据库），这需要文件系统实现DIRECTIO方法。

同样，Fuse也贴心地为我们提供了directIO方式的读写。相比BufferIO方式，DirectIO的最大优势在于减少了数据从应用程序缓冲区拷贝至内核态的开销，对于大量顺序写的应用场景，性能可能会有一定提升。

当然，如果采用DirectIO，恐怕最大的问题就是read也无法使用内核缓存了，很多时候这是我们无法忍受的，常常来说，文件系统读请求会远多于写，所以，优化前望三思。