CJFS: Concurrent Journaling for Better Scalability——论文泛读

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

问题和挑战

重量级的EXT4可扩展性较差，由于日志存在两个限制：日志提交是一个严格的串行活动；日志提交使用原始页缓存条目，而不是其副本，随后任何对正在进行的页缓存条目的访问都将被阻塞。

现有方法局限性

ScaleFS[15]为每个CPU内核[6，8]分配一个正在运行的事务，其中每个内核都分配了单独的文件系统分区。

Son等人[44]对日志事务采用了无锁数据结构。

其他人建议维护多个提交事务。

IceFS[24]和SpanFS[15]将文件系统划分为多个区域。为每个地区分配了一个单独的日志区域，对每个日志区域的日志提交操作可以并行进行。

现有方法无法解决EXT4日志的基本限制；串行提交和提交原始页面缓存条目。在这些工作中，对同一日志区域的日志提交操作仍然是序列化的[15，24]。多个正在运行的事务和多个正在提交的事务可能会相互冲突，如果并发事务相互冲突，则会对它们进行序列化。

本文方法

在这篇论文中，我们提出了并发日志文件系统（Concurrent Journaling Filesystem，CJFS），包含4个优化点：

• 双线程设计。将日志提交操作分为两个独立的任务，将日志块传输到磁盘和使其持久化。我们为每个操作分配一个单独的线程，使用双线程日志，CJFS可以在前一个日志提交仍在进行时提交事务。

  

• 多版本影子分页。CJFS在日志提交中使用更新的页面缓存项的副本，因此事务不存在事务冲突。

  

• 机会合并。发现正在运行的事务与其中一个提交事务冲突时，将正在运行的事务从缩状态释放。通过减轻日志提交中事务的锁开销，增加运行中事务的合并度，即与单个事务关联的系统调用数量。

  

• 复合刷新。为了减轻为刷新命令提供服务的开销，CJFS将并发事务中的多个连续刷新合并为一个刷新，显著减少了单个fsync（）调用的延迟。

  

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

通过消除事务冲突和锁定开销，相比与EXT4，CJFS在filebench varmail、dbench和MySQL的OLTP-Insert上将吞吐量分别提高了81%、68%和125%。

实验

实验环境：Linux内核5.18.18，一台40核服务器（两个Intel Xeon Gold 6230处理器和512 GB DRAM），三星970 Pro SSD（MLC Flash，NVMe）。

数据集：filebench varmail[26]，dbench[46]，MySQL的OLTP-Insert[19]

实验对比：吞吐量、队列深度、fsync()延迟、争用数量

总结

对EXT4文件系统的日志进行优化，日志主要存在两个问题：严格的串行；日志提交使用原始页缓存条目，随后任何对正在进行的页缓存条目的访问都将被阻塞。本文提出CJFS，有四个优化点：双线程设计，将日志提交操作分为两个独立的任务，每个操作分配单独的线程，使用双线程日志，在前一个日志提交仍在进行时提交事务；多版本影子分页，在日志提交中使用更新的页面缓存项的副本，因此事务不存在事务冲突；机会合并，通过减轻日志提交中事务的锁开销，增加运行中事务的合并度；复合刷新，将并发事务中的多个连续刷新合并为一个刷新，显著减少了单个fsync（）调用的延迟。