LWN：fsync()的异步版本

Asynchronous fsync()

By Jake Edge

May 21, 2019

LSFMM

文件系统开发者都很熟悉fsync()的代价，所以他们一直在想办法能提供一些替代fsync()的命令，能减小代价。Ric Wheeler在2019 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM)上就再次讨论了一个提出很久的方法：增加一个async（异步）版本的fsync()。最后看起来他要的功能似乎能用Linux v5.1里包含的io_uring接口来实现。

fsync()的异步版本，乍听起来有点匪夷所思。因为fsync()的目的就是希望确保文件数据全部都写入磁盘，然后再执行后续操作。如果变成异步函数的话，那还怎么保证文件数据都写完了？

Wheeler介绍道，这个功能在大规模数据迁移的时候会很有帮助。假设你在从一台server搬移几千个文件到另一台，那么实际上并不在乎这些文件是不是都是按顺序写入磁盘的。只要确保文件到达对端server之后，就可以删掉本地的文件了。

Jan Kara认为，这个需求有点像syncfs()，不过粒度更细，因为你能选择具体是针对哪个inode来做sync操作。Wheeler还没想好具体用什么样的API，可能会有点像select()。总之这个功能应该很有用，能加速系统。在ReiserFS的时候就有这个想法了，那时候发现，如果按倒序来sync文件，比起按原始顺序来sync要快很多。Ceph, Gluster（都是Redhat旗下的开源存储方案）等都不在乎各个文件具体是按什么顺序写入文件系统的。

Chris Mason认为io_uring就能提供Wheeler需要的功能了。他记得Jens Axboe (io_uring代码作者）已经实现了异步版本的sync_file_range()，不过他不确定fsync()有没有。io_uring的接口可以把任意操作放到kernel worker thread里面，等操作结束的时候，通知到user space。这样的话，实现一个asynchronous I/O（AIO）版本的fsync()应该也不难。大家讨论了一下io_uring如何在各种场景下使用。Wheeler认为至少可以按照Amir Goldstein设想的，实现一种更快的fsync()功能。Mason不太赞成，因为io_uring完全是针对POSIX操作的。Goldstein也这么看，看起来他需要的是某种机制，能够不跟其他的在使用文件系统的workload互相干扰的机制。

Kara认为异步版本的fsync()不会有什么性能提升。毕竟它的底层实现其实还是对一系列文件的逐个fsync()操作。不过Trond Myklebust提醒，user-space的NFS和SMB服务器都会收益，因为不需要专门绑定一个线程来处理fsync()操作。

Wheeler认为如果他要的系统调用最后还是通过一系列的fsync()操作来实现的，那么确实没有什么帮助。Ts'o觉得Wheeler想要的可能是一个fsync2() API，可以接受一组file descriptor作为参数，然后等到它们都被sync之后再返回。只要filesystem支持fsync2()就能批量的做sync操作。这样application开发人员很容易能调用一个函数来实现对一组file descriptor对应文件的sync操作，而不用先要研究清楚io_uring的使用方法。

还有一个很明显的问题，是所有文件都需要做fsync()，还是其实部分文件只需要fdatasync()？也许会需要对每个file descriptor设置一个flag来表明具体需求fsync还是fdatasync？Kara很担心这些file descriptor也许分布在不同的多个文件系统里面，VFS就需要分发系统调用到各个文件系统里去分别处理。Wheeler倒希望能有个方法来限制只能在同一个文件系统里面操作，Kara仍然不赞同，因为application不可能知道每个文件属于哪个文件系统。Ts'o也觉得不要限制只能操作同一个文件系统的文件。VFS还是需要处理这里的复杂性，做好分发工作就好，总比让application developer来使用一个不实用的API要好。