To FUSE or Not to FUSE: Performance of User-Space File Systems

[gaocegege]

FAST'17

来源：@xuanwo

TL;DR

结果很有意思，在 SSD 上的 FUSE 顺序读的性能 overhead 基本都在 5% 以内。随机读的开销还是蛮大的。写的开销基本都不大。开销最大的是 metadata-intensive 的工作负载，频繁的文件元数据操作的场景，基本性能开销都超过了 50%。

[gaocegege]

文章主要讨论了 FUSE 在什么场景更加适合的问题。根据论文的说法，在部分实验中 FUSE 的性能损耗最高可达 -83%，同时 CPU 利用率提高了 31%。

首先 FUSE 之所以在近些年如此受到欢迎，主要有 4 个原因。首先是一些 Stackable 的文件系统相比于传统的文件系统，多了很多新功能，其次是在学术界和研发文件系统的领域，FUSE 能够加速开发迭代和原型设计。再次是一些现存的文件系统也在通过 FUSE 的方式提供支持。最后是一些公司也在使用这一特性开发自己的文件系统。

我感觉这里提到的都不是原因，而是现象。文章在 writing 上多少有点问题。正是因为 FUSE 使得文件系统的开发者和使用者可以在不修改内核的情况下开发和运行文件系统，才会使得有越来越多的企业用户和学术界用户。

所以 FUSE 的核心优势，其实只有一个：脱离内核，便于开发和使用。那么它的劣势也显而易见，由于不在内核态，所以性能相比于在内核中的文件系统，肯定是会差一些。

而开发的方便程度是没有办法量化衡量的，（也有，比如开发相同功能的一个文件系统他，通过 FUSE 和在内核里做花费的时间等，但是不方便发 paper）因此这篇文章主要关注在 FUSE 在性能上到底有多大的成本，来给 FUSE 的用户们一些 insights。知道自己在用什么东西 tradeoff 开发的友好性。

文章是通过实现了一个简单的构建在 EXT4 上的 FUSE 文件系统，跟原生的 EXT4 文件系统做性能上的对比，来说明 FUSE 这一层带来了多大的开销。在一些场景和硬件上，两者表现差不多，但是在最差的 case 上 FUSE 实现的性能降低了 83%。

[gaocegege]

文章提到很多文件系统都只是在用 FUSE 提供的接口在实现自己的文件系统，但是很少有对 FUSE 本身实现的研究。文章的一个贡献就是给我介绍了一些 FUSE 中可能会影响性能的实现细节。

FUSE 由两部分组成，一部分是 kernel 里的部分，一部分是用户态的部分。其中 kernel 态是一个 kernel module（图里蓝色的）。当内核 load 这个 module 的时候，会在 VFS 中注册一个 FUSE 的 file system driver。这个 driver 是一个代理，代理到用户态的文件系统实现中。这个方式让我想到 Nvidia 的 UMD 和 KMD 🤔

Kernel module 除了注册文件系统之外，还会注册一个 /dev/fuse 的块设备。用户态的那个部分是一个 daemon 程序（绿色的），它会跟 libfuse 这样的 library 链接，通过 callback 的方式来接受来自内核的请求。请求主要就是通过 /dev/fuse 的接口进行通信。所以 FUSE 本身会提供一个 kernel module 和一个 lib，我们要实现一个文件系统，只需要 link 它提供的 lib，然后实现对应的回调就好了。

文章里介绍的实现细节确实太细节了，我想大多数人没有了解的必要。。。

[gaocegege]

[gaocegege]

结果很有意思，并不像文章标题那么夸张，在 SSD 上的 FUSE 顺序读的性能 overhead 基本都在 5% 以内。随机读的开销还是蛮大的。写的开销基本都不大。开销最大的是 metadata-intensive 的工作负载，频繁的文件元数据操作的场景，基本性能开销都超过了 50%。