FAST 2022 Paper 分布式元数据论文汇总

问题

现代应用程序努力以崩溃一致的方式保护其数据，这通常分布在多个文件抽象之上。在底层文件系统缺乏事务支持的情况下，应用程序使用复杂的协议来确保跨多个文件的事务性更新，产生长序列的写操作和 fsync() 调用。通过文件系统的事务支持，应用程序可以用单个文件系统事务替换每个输出文件和清单文件的多个 fsync() 调用，通过消除多余的 IO 操作提供更高的性能。

挑战和现有方法局限性

为了成功部署启用事务的系统，必须在四个需求之间找到适当的平衡：易用性、代码复杂性、ACID支持程度、性能。

事务的系统级支持主要可以分为四类：本地操作系统支持[57, 61, 61, 75]、内核级文件系统[14, 26, 27, 46, 55, 66, 72, 78]、用户级文件系统[24, 48, 54]和事务性块设备[12, 28, 32, 52, 58, 65]。

• 将事务作为操作系统一级进行支持是理想的，但它需要对操作系统进行实质性的更改。

• 内核级文件系统的事务支持可以根据ACID支持的程度进一步分类：完整的ACID语义[27, 66]、没有隔离支持的ACD[55, 72]，没有隔离和持久性支持的AC[34]。F2FS中的事务[34]仅支持原子性，而不支持隔离和持久性，且事务不能跨多个文件。尽管它对事务的支持最少，但F2FS是唯一成功将其事务支持部署到公共领域的文件系统。F2FS的事务支持有一个特定的目标应用：SQLite。借助F2FS的原子写，SQLite可以在没有回滚日志文件的情况下实现事务，并消除过多的刷新开销[31, 64]。

• 用户级文件系统的事务支持利用用户级数据库管理系统提供完整的ACID事务[24, 48, 54]，但ACID支持是以性能为代价的。

日志结构文件系统中的事务支持，有三个设计目标：

• 事务应该能够跨越多个文件，包括目录。

• 事务应该能够处理大量更新。

• 事务不应该受到垃圾回收的影响。

本文方法

我们提出了 exF2FS，一种事务性的日志结构文件系统。包括三个关键组件：

• 面向成员的事务。允许事务跨越多个文件，应用程序可以明确指定与事务相关联的文件。

  

• 启用窃取的事务。允许驱逐未提交事务的脏页，同时保证事务的原子性。开发了延迟失效和重新定位记录来实现文件系统事务中的窃取。延迟失效禁止回收页面的旧磁盘位置进行垃圾收集，直到事务提交为止。重新定位记录维护撤消和重做信息以中止和提交被逐出的页面。允许应用程序使用少量内存执行事务，并将大量更新封装到单个事务中（例如，总大小为几十GB的数百个文件）。

• 影子垃圾回收。允许日志结构文件系统在不影响正在进行的事务的原子性的情况下执行垃圾回收。

开源代码：GitHub - ESOS-Lab/xF2FS

使用 exF2FS，SQLite 多文件事务吞吐量相对于原始 SQLite 的多文件事务增加了 24×。当 RocksDB 将压缩实现为文件系统事务时，吞吐量增加了 87%。

实验

实验环境：两种存储设备：Samsung 850 PRO[51]和Intel Optane 900P[29]。Intel CPU i7-9700K（3.60GHz，4核）、64GB内存。

数据集：YCSB，Mobibench

实验对比：吞吐量、垃圾回收、延迟

总结

针对支持事务的文件系统，如何实现事务跨越多个文件、事务处理大量更新、事务不受到垃圾回收的影响。本文提出exF2FS：通过面向成员的事务，允许事务跨越多个文件，应用程序可以明确指定与事务相关联的文件；通过启用窃取，开发了延迟失效（禁止回收页面的旧磁盘位置进行垃圾收集，直到事务提交为止）和重新定位记录（维护撤消和重做信息以中止和提交被逐出的页面），允许应用程序使用少量内存执行事务，并将大量更新封装到单个事务中；通过影子垃圾回收，允许日志结构文件系统在不影响正在进行的事务的原子性的情况下执行垃圾回收。