Samsung：从QLC应用生态来看大容量SSD前景

全文概述

文末材料由Samsung Electronics提供，着重探讨了QLC（四层单元）和高容量存储设备如何依赖开放生态系统以实现成功。随着对大容量需求的增长（64TB、128TB、256TB），传统的4KB或512B LBA格式已不再能满足要求，因此提出了使用更大的Indirection Units（IUs）。这不仅有助于降低能耗，还能简化对高容量硬盘的支持，并减少Write Amplification Factor（WAF）。

文中强调了IUs大于LBA格式带来的挑战，以及为确保I/O操作符合较大IU大小所需的内存管理问题。此外，提出了一种通过Folio抽象来保证内存分配以适应大IU的方法，并讨论了Linux内核对大块尺寸支持的进展，包括即将引入的XFS支持和计划中的大型文件系统功能扩展。

本文还介绍了数据放置技术对于优化QLC性能的重要性，指出它能够利用主机意识的数据放置技术来改善Host-Device之间的数据分布。最后，概述了当前项目状态和未来规划，包括在Linux中增强大块尺寸支持和完成FDP生态系统的开发，以促进无应用变更即可使用的通用工作负载。通过这些努力，旨在通过提高性能和降低成本，使高容量QLC SSD成为可能

生态关注的方向

• 更大块单元（Larger IUs）优化存储性能，通过支持更大的数据块提高效率。
• 数据放置（Data Placement）提供灵活的存储解决方案，提升存储设备在QLC和高容量环境中的表现。

本文主要探讨大容量QLC存储实践过程的上述两个方向的最新进展。

高容量生态系统现状

• 比LBA格式更大的间接单元（IU）已在当前行业中使用
  • 这并非首次出现IU大小大于LBA格式的情况
  • 512字节LBA是当前行业标准，意味着需要RMW
  • 大于IU的写入操作会引发读-修改-写（RMW）问题
  • 起初用于支持4KB和512B的LBA格式
  • 对于64TB的存储容量，16KB的IU已成为规范，而最大LBA格式仍为4KB
  • OCP 2.0在NPWG中对IU进行了标准化
  • 与IU对齐的写入操作可减少能耗
• 对大容量存储（64TB、128TB、256TB）的需求推动更大的间接单元（IU）
  • 垃圾回收（GC）可以在更大的粒度上工作
  • OCP智能健康日志页面 0xC0 SMART-21 记录了未对齐的IU写入
  • 基于操作系统的运行时追踪：Linux trace-cmd / eBPF blkalign
  • I/O验证 -> 许多工作负载已不再使用512B或4KB I/O
  • 可扩展性问题（如总拥有成本TCO、影响范围、可寻址性）
  • 更大的IU更适用于QLC NAND（并简化了高容量HDD的设计）
  • 更大的IU有助于减少写放大系数（WAF）

更多关于 间接单元对存储IO效率的理解，可参考阅读：

• Micron：验证16KB IU对SSD_WAF的影响

Page、LBA和IU的关系

在 SSD 的 I/O 路径上，LBA、IU 和 Page 是从逻辑到物理存储层逐步映射的三大关键抽象层：

• LBA 是主机与存储设备的接口层，定义了逻辑块的位置。
• IU 是 SSD 内部的优化单位，聚合多个 LBA，减少写放大和垃圾回收开销。
• Page 是底层 NAND 闪存的物理存储单位，是所有数据最终存储的地方。

三者的关系可以总结为： 主机通过 LBA 发送 I/O 请求，SSD 控制器将 LBA 聚合为 IU，并通过 FTL 映射 将 IU 转化为 NAND 闪存的 Page。优化这三个层次的交互，是提升 SSD 性能、降低功耗和延长寿命的核心。

三者的相互作用与优化：

(1) IU 的引入缓解了 LBA 和 Page 之间的矛盾

• LBA 的逻辑块大小（通常为 4KB）与物理页大小（如 16KB）不匹配，会导致 RMW 操作：
  • 例如，当主机只写入一个 4KB 的 LBA 块时，SSD 需要先读取整个 16KB 的 Page，将数据合并后再写入回去。
  • 这种操作会增加写放大（WAF），降低性能。
• 引入 IU 后：
  • LBA 的多个小块被聚合为更大的 IU 单元（如 16KB）。
  • SSD 将 IU 与 Page 大小对齐，避免 RMW 操作，提高性能并减少写放大。

(2) 大 IU 对垃圾回收和磨损均衡的优化

• 较大的 IU 有助于垃圾回收（GC）在更大粒度上工作，从而减少 Block 擦除的频率。
• 磨损均衡（Wear Leveling）中，较大的 IU 可以更高效地将写入分布到多个 Block，延长 NAND 闪存寿命。

(3) 高容量 SSD 的趋势

• 随着 SSD 容量的增加（如 64TB、128TB），传统的 4KB LBA 已无法满足性能和功耗需求：
  • 更大的 IU（如 16KB 或 32KB）逐渐成为标准，以适应更高的容量和性能要求。
  • 高容量 SSD 的性能瓶颈更多地依赖于 IU 和 Page 的优化，而非 LBA。

IUs >= 16k 生态系统的挑战

列出了在生态系统中引入大于等于 16KB 的 IU（间接单元）时面临的挑战：

1. 存储格式兼容性：
   • 虽然 IU 变大（>= 16KB），但主流的 LBA 格式仍停留在 4KB，且存储堆栈（包括文件系统和操作系统）仍基于 512b 或 4KB 的假设。
2. 操作系统层面的灵活性：
   • 操作系统可以自由地以 4KB 为单位分割 I/O，这可能导致无法充分利用更大的 IU 优化。
3. 内存管理问题：
   • 保证 IU 大小的 I/O 操作会带来更高的内存管理复杂性。
4. 行业普遍性挑战：
   • 这是一个所有供应商和生态系统的共同挑战，超越了单一厂商的局限性。
5. 耐久性和实际工作负载的差异：
   • 当前 JEDEC 218 标准定义的 DWPD（每日写入耐久性）基于纯随机写入，但这种场景与实际工作负载并不完全一致。
   • 必须根据 IU 对齐进行耐久性（DWPD）调整，以更好地反映真实工作负载的特性。

Linux 系统中的IO支持

左图是操作系统层面的IO路径，上层是用户态，下层是内核态。 基于IO调用方式和深度，存在3种资源调度方式。

• 基于文件系统的IO调度，需抽象出文件的概念；
• 内核对存储块的直接调度，如数据库等应用；
• 内核对底层存储资源的直接访问，如虚拟化场景的SRIOV、GPU直接访问存储等；

以上3种IO访问方式，在适配大IUs 的SSD存储过程中，需要考虑：

• 关键是内存管理
  • 确保内存分配能够满足I/O单元的需求（IU）。
  • 通过Folio抽象实现高效的内存分配管理。
  • 保证连续的内存分配，有助于确保用户提交的I/O大小能够被满足。
• NVMe层级保持稳定
  • LBA（逻辑块地址）格式保持不变。
  • 引入命名空间优选写粒度（NPWG）和原子写单元掉电保护（AWUPF）技术，提高写操作的可靠性和性能。
  • 未来支持更大的LBA格式，扩展存储能力。
• 与原子性保证的目标一致
  • 将原子性操作从软件卸载到硬件，实现更高效的存储操作。
  • 数据库无需写前日志（WAL），即可实现ACID特性（原子性、一致性、隔离性、持久性）。

Folio 技术背景

Folio 是 Linux 内核中一个内存管理层的抽象概念，用于优化大块内存（例如多页内存）的管理和操作。它是从传统的“页（page）”概念发展而来的，目的是解决基于单页管理在现代高性能场景下的局限性。

传统内存管理中的问题

• 基于单页的管理效率低下：
  • 高管理开销：每个单页都有自己的元数据，随着内存量的增加，管理单页的成本会迅速增加。
  • 碎片化问题：单页的分配和释放容易造成内存碎片，影响系统的性能。
  • 性能瓶颈：大数据处理和高吞吐场景（如数据库、存储设备）需要频繁访问大量连续内存，但单页管理会降低 I/O 和 CPU 的效率。
  • Linux 内核传统上使用单页（通常是4KB或更小）的单位来管理内存。对于存储子系统、文件系统或大型内存操作场景，这种方法会导致：
• 大块内存的需求：
  • 文件系统和存储子系统往往需要以更大粒度（如 64KB、128KB，甚至更大）来管理内存，以更高效地处理数据。

Folio 的引入

Folio 是为了解决上述问题而引入的，提供了一种 大块内存管理的抽象。一个 Folio 包含一个或多个连续的物理页，并通过一个统一的结构来管理它们。

核心特性：

1. 批量管理：
   • 一个 Folio 由多个连续页组成，减少了每页单独管理的开销。
   • 元数据共享：将每个页的元数据统一为一个 Folio 元数据。
2. 减少碎片化：
   • Folio 能够更好地支持大块内存分配需求，避免频繁分配和释放小块内存导致的碎片问题。
3. 支持文件系统和存储优化：
   • 文件系统（如 XFS、Ext4）可以通过 Folio 更高效地管理内存页。
   • 更适合现代存储设备（如 NVMe 和 SSD），支持更大的 I/O 单元（I/O Unit）。
4. 简化代码和逻辑：
   • Folio 让内存管理更容易理解，简化了文件系统与存储子系统的开发代码。

大存储块的应用路线图

LBS的落地需要软件层的大量适配工作，不同资源调度方式的路线图有时间差异。

• IO透传/直接访问 I/O透传和块直接I/O支持的单元大小（IU）已经扩展到256KB。
• 基于文件系统的IO调度 计划在Linux内核6.12版本中增加对XFS文件系统的支持。 启用页面缓存的块支持（Block w/ Page Cache）预计在2024年底完成。 BcacheFS文件系统的支持计划在2024年底推出。 Btrfs和Ext4文件系统支持正在社区开发中
• 用户态直接访问 计划中

LBS生态系统展示了Linux对大块大小存储设备的持续优化。 通过支持更多文件系统（如XFS、BcacheFS），以及逐步扩展单元大小（IU）至2MB，提高了存储效率和性能。 核心开发采用开放模式，为社区贡献者提供参与机会，同时推动Linux存储技术的发展。

MySQL在16KB块大小下的表现

• 实验环境:
  • 使用MySQL数据库，运行12小时的sysbench性能测试。
  • 主要测试不同I/O大小和对齐方式下的性能表现。
• 图表解析:
  • AWUPF（原子写单元掉电保护）开启时，在16KB块大小下关闭innodb_doublewrite功能，TPS波动显著降低。
  • TPS的变动性降低了3到5倍（绿色点的分布更均匀），表明性能更加稳定。
  • 对齐和未对齐情况下的I/O表现对比。
  • 对齐的16KB和32KB块大小显著高于其他块大小，表明对齐能够显著提升I/O效率。
  • 在16KB和32KB块大小下，I/O次数明显高于其他大小，说明这两个块大小在测试中更高效。
  • 左上图：I/O大小对I/O次数的影响 不同块大小（从512B到512KB）的I/O次数统计。
  • 左下图：I/O对齐对性能的影响
  • 右图：TPS（每秒事务数）表现
• 结论:
  • 块大小优化16KB和32KB是MySQL I/O的最优块大小，能够带来更高的性能和更低的波动性。
  • 对齐的重要性I/O对齐进一步优化了性能，尤其是在16KB和32KB块大小下表现更为明显。
  • AWUPF与TPS稳定性通过AWUPF优化，关闭innodb_doublewrite可以显著提升MySQL事务的稳定性。

QLC中的数据放置

• QLC存储优化:
  • FDP提供了一种主机感知的数据放置方式，能够提升数据管理和写入效率，特别适用于QLC NAND的性能优化。
  • 集成历史技术（如ZNS、OCSSD），进一步拓展适用场景。
• 生态系统成熟:
  • FDP生态系统已经简化，针对块和文件层的内核支持正在推进。
  • 应用层无需修改即可适配流式数据支持，便于快速部署。
• 企业价值:
  • 适配超大规模和企业级存储环境，提高了存储设备的性能和灵活性，为企业提供更高效的存储解决方案。

更多关于 FDP 的厂商实践，可参考阅读：

• FDP与SSD主控创新

FDP：真实部署数据

• 左侧：Cachelib的测试数据
  • 测试条件在不同SSD利用率（60%、70%、80%）下比较启用FDP和未启用FDP的表现。
  • 结果启用FDP后（蓝线），写放大因子（WAF）显著降低。 随着SSD利用率的增加（从60%到80%），启用FDP的优势更加明显，WAF始终保持较低水平，而未启用FDP（红线）的WAF逐渐上升。
• 右上图：MySQL（InnoDB）的测试数据
  • 测试条件在TPC-C负载下，比较启用和未启用FDP的WAF。
  • 结果未启用FDP时（蓝线），WAF逐渐增高，最终达到1.44。 启用FDP后（橙线），WAF保持较低水平，最终为1.25，性能更优且波动更小。
• 右下图：RocksDB的测试数据
  • 测试条件使用YCSB工作负载，在FDP插件、Ext4文件系统、XFS文件系统下进行比较。
  • 结果FDP插件的WAF表现最佳（蓝线），最终稳定在1.70。 Ext4的WAF较高，达到2.88。 XFS的WAF最高，为3.43。
• 关键发现: 启用FDP后，WAF显著降低，不同负载下均表现出更高的效率和稳定性。 在高SSD利用率和复杂负载场景中，FDP的效果尤为突出。 FDP插件优于传统文件系统（如Ext4和XFS），适合高性能数据库（如MySQL、RocksDB）和Cachelib等场景。

• 大块单元（Large IU）：
  • 当前进展NVMe和块层（Block Layer）的大块单元支持已基本完成。 当前工作集中于文件系统的支持，一些补丁已发布。
  • 与社区合作与社区合作定义Linux堆栈中对IU（单元大小）边界的限制。
  • 下一步计划在不改变应用程序的情况下，量化大块单元对通用工作负载的性能提升。
• 数据放置（Data Placement）：
  • 目标完善FDP（灵活数据放置）生态系统开发，进行维护与优化。
  • 关键工作支持通用工作负载运行，无需修改应用程序。 在操作系统级别分离元数据管理，特别针对遗留负载和通用硬件SKU，简化部署流程。
  • 未来计划维护简化的操作系统API，并支持更多高影响力的应用程序。 与行业合作，扩展FDP到更多新用例，包括标准化和开放生态的场景。