【论文解读】小而工整的研究范文：SSD 硬件赋能加速事务写 (FAST'25)

引言

存储领域顶会 FAST 2025 一共收录 36 篇论文（接受率为21.6%），其中一大特色方向是 SSD 硬件赋能软件——利用 SSD 的高级硬件功能特性解决存储软件开销问题，相关有 7 篇论文（参见本文末尾）。本文评述其中一篇解决崩溃一致性问题的文章。

文件系统、数据库等核心软件长期以来依赖“日志”（Journaling or Write-Ahead Logging）等软件方案来提供事务写原子性，实现崩溃一致性保障。这类方案存在“双写”开销，导致写放大和性能损失。在 SSD 存储设备越来越快的当下，这一问题显得日益突出。

幸运的是，SSD 底层的闪存介质以页为单位进行写入，该物理特性能够外化为原子写接口。NVMe标准将该特性定义为“Atomic Write Unit Power Fail (AWUPF)”，对于不大于 AWUPF 尺寸的写操作，即使在写入过程中发生断电，设备也能保证完整的数据被持久化到闪存并后续被正确读取，而绝不会是损坏的、写了一半的数据。

该论文提出利用 SSD 的硬件级原子写特性 AWUPF 来为减轻上层软件的崩溃一致性保障开销，且无需对 SSD 固件或硬件接口做任何修改。具体而言，面向日志结构 RAID（Log-RAID）系统，利用 AWUPF 原子写避免映射元数据日志开销。该工作由韩国成均馆大学的Jiyune Jeon等人完成。本文对该工作进行解读和评述，内容包括以下几个方面。

• 背景介绍。简单介绍固态盘 AWUPF 原子写特性和 Log-RAID 技术。

• 论文解读。依次介绍研究动机、设计概要、以及实验评估。

• 论文评述。该论文呈现了一个“小而工整”的研究工作，其简单清晰的研究思路和行文逻辑值得新手学习；在技术贡献上，它微创新了一个小的技术连接，方法实用（设计哲学方面）而又不实用（适用性有限）。

1. 背景介绍

（1）闪存固态盘的 AWUPF 原子写特性

AWUPF 是 NVMe 规范中的一项强制性功能。当 SSD 执行写命令时，数据首先被写入内部 DRAM 缓存，然后编程持久化到闪存页，最后 FTL 会更新逻辑到物理地址的映射表。为应对突发断电，SSD 通常配备有电容和掉电保护机制，确保缓存中的数据和映射表更新能够安全写回闪存。AWUPF 正是利用这一机制，为单个、地址连续且尺寸不超过特定限制（AWUPF 值，通常为4KB，但有特例可达256KB）的写命令提供原子性保证。尽管这是一个早已存在且标准化的功能，但在该论文发表之前，几乎没有公开的工作利用该功能优化主机软件的事务处理。

（2）日志结构RAID（Log-RAID）技术

论文选择 Log-RAID 作为其研究和优化的对象。传统 RAID 将数据块静态映射到不同 SSD 设备上，而 Log-RAID 以日志追加（Append-only）的方式将所有写入（无论是随机还是顺序）都转换成大且连续的条带（Stripe）写入到 SSD 阵列中。这种方式天然地匹配了闪存“先擦除再写入”且“顺序写性能远高于随机写”的特性，能够有效降低 SSD 写放大，提升性能和寿命。

然而，这种设计的代价是数据块的存储位置是动态变化的。因此，系统必须维护一个“逻辑地址”到“物理地址”的映射表。如下图所示，以 Poseidon OS 中的 Log-RAID 为例，映射元数据 VSA map 包括用户可见的虚拟块地址到虚拟条带号 VSID 和条带内偏移的映射❶，以及虚拟条带到其存储地址的映射❷。当数据被写入时，映射元数据也必须随之更新❸。为在断电等意外情况下保障数据和元数据的一致性（例如，避免出现元数据更新了但数据没成功写入），Log-RAID 采用日志机制来保护这些元数据更新。具体而言，先将元数据变更记录到日志区域，然后当日志区域写满时，通过检查点（checkpoint）机制将记录的变更日志批量更新到存储的映射元数据页中，即存在元数据“双写”开销。

2. 论文解读

（1）研究动机：元数据日志引发严重性能开销

论文以 Log-RAID of Poseidon OS (POS) 为研究对象，如下图所示，相比于不开启日志，为映射元数据 VSA map 开启日志时系统性能大幅降低，尤其是在小写请求下。该开销来源于两方面，一是，在写 IO 关键路径上需要额外写一次元数据日志；二是，日志区域写满时需要触发耗时的 checkpoint 操作。论文探索的核心问题是：能否利用 SSD 现有的 AWUPF 功能来降低这一性能开销？

（2）设计概要：双路径更新策略 + 顺序性保障机制

针对 Log-RAID 的 VSA map 映射元数据更新，论文提出了一种轻量级优化方案，核心思路是采用双路径更新策略。

• 直接更新路径：当一次元数据更新只涉及一个大小不超过 SSD AWUPF 尺寸（如 4KB）的连续区域，系统直接将元数据页从内存写回存储设备，由 AWUPF 特性保证其原子性，避免日志写入（“双写”变“单写”）。

• 日志路径：如果元数据更新区域超过了 AWUPF尺寸，或者跨两个元数据页，那么系统回退到传统的日志路径，先将变更写入日志区，后续再通过检查点（checkpoint）机制将变更持久化到元数据存储区。

• 版本号：为每个元数据页 mpage 设置一个64位的头部，其中63位用作版本号。每当对一个mpage进行直接更新或日志提交时，其版本号自加一。在系统崩溃恢复时，通过比较日志记录的版本号和存储区中的版本号，来确定哪个是最新版本，从而避免旧的日志数据覆盖新的直接写入数据。

• “使用中”标志位：头部剩下的1位用作“使用中”标志。当一个日志事务开始处理某个mpage时先设置该标志，如果此时有一个直接更新也想修改这个mpage，它会发现该标志位被设置，此时它将不会增加版本号。这可以防止一个快速的直接更新（版本号+1）在一个慢速的日志事务（版本号+1）之后完成，导致日志事务在恢复时因版本号较低而被错误地丢弃。
• 延迟内存更新：对于走日志路径的写操作，其对内存中元数据副本的修改被推迟到日志提交完成之后才进行。这可以防止在日志提交完成前发生崩溃，导致另一个直接写操作将包含了未提交数据的“脏”内存页持久化到存储中。
  

（3）实验评估：随机小写性能显著提升

实验环境与方法：在开源存储操作系统 Poseidon OS上实现所提出的方法，实验平台配备了高性能 Intel Xeon处理器和 10 块三星PM9A3 SSD（AWUPF 为 4KB）。对比以下两种方案，测试负载使用了微基准测试工具FIO和更能模拟真实应用场景的Filebench。

• Journaled：所有元数据更新都通过日志保证一致性。
• Direct：元数据更新都不做保护地直接写入，用于衡量性能理论上限。
  

主要评估结果：

• 随机小IO性能显著提升：在 FIO 4KB 随机写测试中，提出方法的性能高达 Journaled 的 3.6 倍，几乎达到了 Direct 的理论上限。这是因为这种负载会产生大量离散的小规模元数据更新，完美匹配了AWUPF直接路径的优势，从而避免了日志和检查点带来的巨大开销。
• 可扩展性增强：随着元数据处理线程数的增加，Journaled方法由于检查点瓶颈，性能提升有限，而提出的方法则展现出良好扩展性。
• 真实负载表现优异：在 Filebench OLTP（在线事务处理，以小随机写为主）负载下，提出的方法取得了最高 73% 的性能提升。在 varmail （邮件服务器，混合读写）负载下，获得了 14% 的性能提升。对于以大文件顺序写为主的 fileserver 负载，性能差异不大，因为大 IO 触发日志路径的概率更高。

• 有趣的意外发现：在某些情况下，提出方法的性能甚至略微超过了理论上限的 Direct 配置。原因是，当一次更新跨越多个元数据页时， Direct 方法需要发起多个独立的写操作，可能会受到“慢线程”拖累；而 提出的方法此时会走日志路径，将多次更新合并为一次更小的日志提交，反而效率更高。
  

3. 论文评述

（1）“小”的研究工作

“小”的含义在于：

• 微创新了一个小的技术连接：其核心思想是利用 SSD AWUPF 原子写硬件特性避免存储软件的日志开销，解决方案是双路径更新策略，它们在逻辑上都较为简单直观，谈不上精巧。在软硬件协同设计的思想大潮下，将事务写功能卸载到 SSD 的研究早在 2008 年就已经出现（Transactional flash [OSDI'08]），后续研究也不在少数（如 EAW [SOSP'13]、X-FTL [SIGMOD'13]、SHARE [SIGMOD'16]）。

  关于如何定位该工作的贡献，论文标题中的“Rediscovered”一词用得很准确，AWUPF 并非新技术，它作为 NVMe 标准的一部分早已存在，但长期以来，它主要被设备制造商用于保障 SSD 自身的内部数据完整性，而被上层软件所“遗忘”。该工作的主要贡献在于做出了一个新的小连接——在 SSD AWUPF 硬件特性与存储软件的日志开销问题之间。

• 实用而又不实用：实用之处在于设计哲学，传统的硬件功能卸载设计通常需要定制化修改 SSD 设备，而该工作利用的是标准化、通用的硬件特性，消除了特定硬件依赖，部署成本低。

  不实用之处在于所提出方法的适用场景十分局限，论文仅仅探索了在日志结构 RAID 系统中的应用。相比而言，之前的大量事务写功能卸载研究主要面向的是文件系统和数据库，应用范围广、价值高。

  笔者在读完该论文之后产生的第一个疑问就是，为什么它不做更多的案例研究，探索所提出方法在更多场景下的应用效果。系统研究重视系统性和实践性，如果能够在多个应用场景下证明所提出的方法具有良好的应用效果，那么该工作的价值将上升一个档次。

  遗憾的是，论文在 Introduction 中介绍 Log-RAID 案例研究之前就提到，将此方法推广到通用的文件系统充满挑战。因为在文件系统中，创建一个文件可能需要同时修改inode位图、数据块位图、inode表、目录项等多个分散在不同位置的元数据结构，很难将它们打包成一个满足AWUPF尺寸限制的单一连续写。

  另外顺便一提，从论文写作的角度看，在 Introduction 中重要的关键逻辑节点上先去说明所提出方法的重大局限，不是一个明智的选择。一种更好的处理方式是，先正面描述方法的价值和应用效果，然后在设计末尾或结论章节再去讨论方法的局限性。

（2）“工整”的研究工作

另一方面，这篇论文的逻辑链条十分“工整”，总结如下。该论文可作为范文，其简单清晰的研究思路和行文逻辑值得新手去学习和效仿。

1. 问题：为保障崩溃一致性，基于日志的软件方法性能开销大；

2. 发现：SSD 硬件有原子写功能，提供了一条新路经；

3. 思路：该新路径存在 AWUPF 尺寸限制，因此结合传统的日志方法形成动态的双路径设计；

4. 挑战：该设计的实现存在一个顺序性保障挑战，因此针对不同情况分别采用一些简单策略应对；

5. 评估：实验证明该设计能有效提升系统性能。

附：FAST 2025 “SSD 硬件赋能软件” 方向的 7 篇论文。