ZNS SSD垃圾回收优化方案解读-1

本文解读的论文《Optimizing Garbage Collection for ZNS SSDs via In-storage Data Migration and Address Remapping》是由重庆大学相关研究团队撰写,发表于2024年11月。本文小编将结合论文内容进行学习解读,以供各位读者参考!由于水平有限,如有错误之处,欢迎在本文底部留言或者私信交流,感谢支持!

扩展阅读:


在固态硬盘(SSDs)技术发展进程中,传统块接口与闪存特性的不匹配引发了诸多严重问题,如高写放大、大量预留空间需求以及页级映射所需的额外 DRAM 等,这促使了 NVMe Zoned Namespace(ZNS)接口的诞生。

ZNS 接口作为闪存 SSDs 的新兴高性能标准,通过将逻辑地址空间划分为固定大小的顺序写入区域,有效减少了映射表的 DRAM 需求,并将设备内垃圾回收(GC)和数据放置职责转移至主机,从而降低了预留成本和写放大,还避免了日志堆叠问题,使得应用能够依据数据生命周期顺序写入不同区域,进一步减少 GC 导致的写放大。

然而,ZNS SSDs 的主机端 GC 仍存在显著缺陷。尽管已有研究致力于提升其 GC 性能,如通过分离冷热数据的日志结构合并式区域 GC、基于键值数据特征的生命周期感知数据放置以及整合 LSM - Tree 压缩和主机端 GC 等方法来减少有效数据迁移开销,但由于 SSD 空间使用需求,GC 过程仍会引发大量数据迁移,尤其在写密集型工作负载下更为突出。数据迁移不仅会产生不必要的端到端传输开销,即有效数据需先传输至主机缓冲区再写回设备,而且由于 GC 以区域为粒度执行,存在严重的块到块重写开销,即便命中区域块内多数数据有效,仍需按预配置映射重写到目标区域,且顺序写入特性常使命中分区块内存在大量有效数据,进一步加剧了问题的严重性。

一、ZNS SSDs 主机端 GC 现存问题剖析

  1. 数据迁移的端到端传输开销:在传统的 ZNS SSDs 主机端 GC 过程中,数据迁移流程复杂且低效。当进行垃圾回收时,数据首先需要从设备的源区域传输至主机缓冲区。这一过程涉及数据在设备与主机之间的大量传输,消耗了宝贵的系统资源与时间。随后,数据再从主机缓冲区写回 SSD 的目标位置。这种先上传再回写的方式,产生了不必要的端到端传输开销,极大地降低了数据迁移的效率,增加了系统的整体延迟,尤其是在处理大量数据时,对系统性能的影响更为明显。
  1. 块到块重写开销:ZNS SSDs 中区域与块之间存在预配置的映射关系。在 GC 操作时,这种映射机制引发了严重的块到块重写问题。由于是基于区域进行回收操作,即便某个命中区域(victim zone)中的块内大部分数据是有效的,按照预配置的映射规则,这些有效数据仍需全部迁移并重新写入目标区域(target zone)的其他块中。例如,在实际的数据存储场景中,可能存在一个块内 80%的数据都是有效且仍在频繁使用的数据,但在传统 GC 过程中,这些数据不得不被重写,导致大量的写入操作,不仅浪费了存储设备的写入寿命,还显著增加了系统的 GC 延迟,严重影响了 SSD 的整体性能与使用寿命。

为解决这些问题,**本文提出了具有动态区域映射功能的新型 ZNS SSD 设计------Brick-ZNS。**其主要创新点包括:设计新的 ZNS 命令实现存储内数据迁移,消除 GC 数据迁移的端到端传输开销;构建动态区域映射机制,利用并行物理块实现区域和块的动态重映射,并确保芯片间并行性;提出 GC 过程的重映射策略,降低昂贵的块到块重写开销。通过在全 I/O 真实链路环境下的一系列实验及综合分析,有效评估了该方案的有效性,为 ZNS SSDs 的性能优化提供了新的思路与方法,有望推动闪存存储技术在 GC 效率和整体性能方面的进一步提升,在存储领域具有重要的研究意义和应用价值。

二、ZNS SSDs 基础架构与命令体系

NVMe ZNS 作为闪存 SSDs 的高性能接口,其核心创新在于将设备逻辑地址空间划分为多个固定尺寸区域,各区域配备写指针确保顺序写入并与物理块对齐。这种设计使得 ZNS SSDs 能够借助高效的区域数据放置机制降低写放大,并通过粗粒度区域映射减少 DRAM 需求。在实际应用场景中,如 LSM - tree 键值存储、日志结构文件系统、内存交换、缓存及 RAID 系统等,ZNS SSDs 性能表现优于传统块接口 SSDs。

ZNS 规范定义了主机与设备交互的系列命令,包括 Zone_Read、Zone_Write、Zone_Mgmt 和 Zone_Append,通过 PCIe 总线传输并在设备区域转换层解析执行。然而,数据迁移时仅依靠读写命令导致数据需先从设备读至主机缓冲区再写回设备,产生不必要的端到端传输开销,成为影响性能的关键因素之一。

1. ZNS SSDs 当前区域映射机制剖析

尽管 ZNS 规范未明确区域映射规则,但现有研究揭示了其遵循的两个重要原则。其一,采用粗粒度块级映射组织区域,有效削减映射表 DRAM 占用;其二,将区域映射到跨不同闪存芯片的多个物理块组,利用闪存芯片 I/O 并行性,其中并行块组(PBGs)可并行读写,PBG 内芯片数量可由设备商配置,如典型的 4 芯片 PBG 示例中,其物理页按特定顺序写入确保芯片间并行与块内顺序写入。

但在垃圾回收过程中,这种基于区域的粗粒度 GC 机制暴露出严重弊端。由于需按预配置映射回收区域空间,无论命中块内有效数据比例高低,所有数据都将被重写到目标块,如含 80%有效数据的 PBG 迁移 80%数据仅释放 20%空间,极端情况下全有效 PBG 也会被重写,极大降低了数据迁移效率,严重损害 ZNS SSDs 整体性能。

2. ZNS SSDs 运行时区域重置与主机端垃圾回收机制

得益于区域数据放置策略,部分区域数据可同时失效实现空间释放,即运行时区域重置机制,但在实际应用中,因闪存的异地更新特性,写密集型工作负载仍需垃圾回收提升空间利用率,故该机制仅能减少 GC 调用次数而非完全替代。与传统 SSDs 不同,ZNS SSDs 将 GC 职责转至主机,且主机端 GC 以区域为粒度重置,远超传统块擦除单元。

主机端 GC 包含命中区与目标区选择、有效数据迁移和命中区重置三个子任务,但当前有效数据迁移过程效率极低。一方面,受限于 ZNS 命令集,数据迁移产生高额端到端传输开销;另一方面,区域块映射配置致使块到块重写开销巨大,这些开销严重削弱了主机端 GC 的优势。因此,优化 ZNS SSDs 主机端 GC 数据迁移成为关键研究方向,后续研究将基于相关实验分析深入探讨改进策略,以突破现有性能瓶颈。

三、数据分布与主机端 GC 开销解析

1. 无数据迁移下的有效数据分布洞察

基于全栈 SSD 模拟器(FEMU)构建的 ZNS SSD 设备(搭载 RocksDB 和 ZenFS)实验表明,在未进行数据迁移(仅启用运行时区域重置)且所有区域均已分配的情况下,多数区域空间利用率极低,平均仅约 40%。ZenFS 采用基于区域的数据放置策略,虽理论上可使同一区域内具有相同生命周期的数据同时失效以提升效率,但实际环境中数据放置难以达理想状态,数据迁移仍不可或缺。

对于不同类型工作负载,如随机写入(Ran)及随机写入加更新(Ran + UR)的前两类负载,多数区域有效数据约占 50%;而顺序写入(Seq)及顺序写入加更新(Seq + UR)的后两类负载,多数区域有效数据仅占 30%左右。由于数据生命周期受诸多外部因素影响难以精准预测,即便同一区域内数据预期寿命相同,也并非能同时失效,只要存在有效数据,区域内大量无效空间便无法回收。在写密集型工作负载下,区域消耗速度远超回收速度,极端情况下所有区域均含有效数据而无法回收,导致严重写入停顿与极低空间利用率,凸显了垃圾回收(GC)对保障可用区域及提升空间利用率的关键必要性。

2. 主机端垃圾回收开销深度分析

针对 ZNS SSDs 实施 Greedy 和 Cost - benefit 两种近期 GC 策略进行研究,二者在区域占用率达 70%时启动 GC,每次回收 5%区域,并启用运行时区域重置减少 GC 调用次数。主机端 GC 数据迁移平均延迟高达 123 秒,涵盖块到块重写、端到端传输及区域重置开销。其中,端到端传输延迟(平均占总 GC 延迟 17%)包括命令传输与数据传输延迟,分别由主机读写命令发出及设备与主机间数据传输所致。

数据重写开销是 GC 延迟的主要因素,平均占比达 72%。根源在于当前基于区域的 GC 机制,无论命中块内有效数据量多寡,均需重写所有数据以释放空间。分析命中块内有效数据比例发现,平均 25%的命中块有效数据超 70%,22%的命中块回收时全部为有效数据。这是由于顺序写入使区域内相同物理块常写入同一文件数据,导致有效数据集中于某些块,引发严重块到块重写开销,即大量有效数据从命中块迁移至目标块。

ZNS SSDs 主机端 GC 受高数据迁移开销严重制约,包括端到端传输与块到块重写开销。此现状迫切催生创新 GC 方案,通过存储内数据迁移消除端到端传输开销,并借助地址重映射降低块到块重写开销,为后续研究指明方向,成为提升 ZNS SSDs 性能的关键突破点。

相关推荐
zfj3211 小时前
学英语学技术:Elasticsearch 线程池
大数据·elasticsearch·搜索引擎
白白糖2 小时前
深度学习 Pytorch 张量的索引、分片、合并以及维度调整
人工智能·pytorch·python·深度学习
白白糖2 小时前
深度学习 Pytorch 张量(Tensor)的创建和常用方法
人工智能·pytorch·python·深度学习
王子良.3 小时前
Hadoop 与 Spark:大数据处理的比较
大数据·hadoop·spark
Noos_3 小时前
AI面试官
人工智能
Lethehong3 小时前
Red Hat8:搭建FTP服务器
linux·运维·服务器
lovelin+v175030409663 小时前
从零到一:构建高效稳定的电商数据API接口
大数据·网络·人工智能·爬虫·python
深度学习实战训练营3 小时前
基于机器学习的电信用户流失预测与数据分析可视化
人工智能·机器学习·数据分析
小白狮ww4 小时前
LTX-Video 高效视频生成模型,一键处理图片&文字
图像处理·人工智能·深度学习·机器学习·音视频·视频生成·ai 视频
ayt0074 小时前
【Flink系列】4. Flink运行时架构
大数据·架构·flink