FastCommit: resource-efficient, performant and cost-effective file system journaling——泛读笔记

ATC 2024 Paper 分布式元数据论文阅读笔记整理

问题

JBD2是Ext4的物理日志机制，它存储了修改后的文件系统元数据块的完整副本，如空闲块位图、索引节点、目录条目等，作为应用程序调用fsync提交的一部分。物理日志（包括JBD2）在恢复过程中被设计得简单高效，但在提交过程中会产生较高的字节和IO开销。在元数据负载繁重时，应用程序发出的fsync会导致JBD2写入更改的元数据块的副本，从而产生高字节和IO开销。例如，JBD2通过两个单独的IO操作，每次提交至少存储三个块（12KB），平均存储6个块（24KB）。在多线程邮件服务器工作负载中，将端到端应用程序吞吐量降低了45%，并将fsync延迟增加了280%。当通过NFS在Ext4中存储数据时，NFS协议会为每次文件元数据更新发出fsync，进一步加剧了问题。相同的邮件服务器工作负载在NFS异步上会发出26倍的fsyncs，将端到端吞吐量降低8倍，在NFS异步设置中，76%的写入带宽由JBD2消耗。

本文方法

本文提出了FASTCOMMIT，用于Ext4的混合日志记录方法。JBD2每5秒提交一次，在这5秒内，FASTCOMMIT会尝试在逻辑上记录文件系统更新，并在无法执行逻辑日志记录时（文件系统大小调整等复杂和罕见的操作的情况下）退回到传统的JBD2。有效地将JBD2提交与fsync解耦。

• 紧凑型日志记录（FCLog），减少字节开销。在一个FCLog中，将许多文件系统更新（FCTags）打包，并放在一个磁盘块（4KB）内。

• 选择性刷新，减少IO开销。使用强制单元访问（FUA）IO命令[15]，将适合单个块的FClog持久写入底层存储介质。这些提交不需要发出昂贵的缓存刷新命令[36]（除非在事务提交期间需要刷新任何数据）。两种方法结合，确保超过80%的提交包含在一个4KB的块中。

• 内联日志，减少上下文切换延迟。由于FASTCOMMIT提交量小且速度快，因此发出fsync的线程的调度优先级会被临时提升，以匹配执行提交的JBD2线程的优先级，从而防止上下文切换延迟并改善fsync延迟。

实验表明，与JBD2相比，FASTCOMMIT将fsync延迟减少约65%，产生的字节、IO和缓存刷新开销分别降低了63%、42%和79%。FASTCOMMIT的资源高效日志记录最大限度地减少了多租户环境中的干扰，使总运行时间减少了近20%，与JBD2相比，两个同时运行的工作负载的吞吐量分别提高了80%和23%。

总结

针对Ext4的日志机制JBD2，在提交过程会产生高字节开销和I/O开销。本文提出FASTCOMMIT，用于Ext4的混合日志记录方法，短期维护逻辑日志，定期写入物理日志。包括3个技术：（1）紧凑型日志记录，减少字节开销，将许多文件系统更新打包放在一个磁盘块内。（2）选择性刷新，减少IO开销，将适合单个块的日志持久写入底层存储介质，避免缓存刷新命令。（3）内联日志，减少上下文切换延迟，发出fsync的线程的调度优先级会被临时提升，以匹配执行提交的JBD2线程的优先级，从而防止上下文切换延迟并改善fsync延迟。