引言
在上次存储随笔更新了一篇ZNS相关的文章“炙手可热的ZNS SSD将会为数据中心带来什么?”以后,在存储圈也一度引发关注。某公司相关同学也在朋友圈疯狂转发,让一些朋友误以为是存储随笔专为某公司写的技术推广软文。
借这个机会在这里再次声明,存储随笔没有接受任何技术软文广告推广的合作,是个人运营账号,文章内容基本为个人独立创作(除了个别来自其他作者授权的原创内容)。
如上图,借用一位粉丝的留言,非常感谢各位存储随笔粉丝的认可与支持。存储随笔始终坚持业界良心,原创分享,共同成长!
前情回顾:
言归正传,此前文章(炙手可热的ZNS SSD将会为数据中心带来什么?)我们介绍了ZNS(Zoned Namespace) SSD的一些背景和原理。
ZNS SSD的原理是把namespace空间划分多个zone空间,zone空间内部执行顺序读写。这样做的优势:
-
降低SSD内部的写放大,提升SSD的寿命
-
降低OP空间,host可以获得更大的使用空间
-
降低SSD内部DRAM的容量,降低整体的SSD成本
-
降低SSD读写延迟
-
ZNS写入了标准NVME协议,更易于打造软件生态,利于普及
与SMR架构类似,ZNS SSD的zone空间内部,也是只允许顺序读写,不允许随机读写。每次顺序写完成后,有一个标记位“Write Pointer”来记录已经写过数据所在的LBA位置。
Zone的状态有以下几个:
-
Full:zone写满的状态
-
Empty:zone数据空的状态
-
Explicitly Opened:对zone执行open zone命令成功后的状态
-
Implicitly Opened:对处于Empty或者Closed状态的zone完成写数据后的状态
-
Closed:还未写满的zone,在close zone命令成功后的状态
-
Read Only:处于只读状态的zone
-
Offline:zone处于异常状态,可能是介质异常或者其他的问题
在Linux内核适配方面,针对zoned设备,之前针对SMR已经有ZAC/ZBC命令规范,并在4.10内核已经支持。针对ZNS SSD,在内核5.10以后也支持了ZNS SSD,软件生态已经基本完善。
ZNS的竞争优势?前途如何?
在传统的SSD中,SSD控制器会搭配10-100个NAND Die存储介质,管理这些NAND介质就需要一个强大的算法,这里就有一个FTL管理层。
如果在文件系统层删除一个文件,比如下图文件C,在没有GC搬迁的情况下,无效数据C会占用大量的存储空间。
GC搬迁有效数据到空的block后,之前无效文件C所在数据块block就可以被整个block擦除了。
整个GC的过程最终导致写放大WAF的增加。写放大的增加相应对SSD带来的负面效应就是写带宽下降、读延迟升高、使用寿命下降等问题。
扩展阅读:SSD写放大的优化策略要统一标准了吗?
在ZNS的场景下,不同应用按照Zone配置信息,相应存放业务数据。主要集中在顺序读写的workload场景。由于是Host管理数据的摆放和存取位置,会最大程度减少GC垃圾回收。
减少SSD的DRAM空间和去掉OP冗余空间,提升用户可用的容量。
二者具体的优劣对比:
ZNS SSD可以使用的场景主要有几个:
1.数据归档存储场景
在归档场景,需要有大量的数据存储,归档存储主力当前主要是SMR HDD和Tape磁带库。在SMR HDD和Tape磁带库可以增加一层不是特别cold数据存储层,使用ZNS搭配QLC,后续可能还有ZNS搭配PLC的产品。核心诉求是降成本、降低写放大/OP/DRAM容量。这个场景就需要zone的空间要大一点,需要一些大QD的写入。
2.Log日志场景
日志场景主要依赖当前基于flash友好的文件格式。这个场景可能需要zone的空间需要可配置变化。小容量的zone配置数据分配和切割,大容量zone配置数据放置和管理。每个zone的数据保持不变。
3.可预期IO场景
解决多租户的IO干扰问题,获得优异的QoS性能。该场景需要有多租户的需求且有严格QoS需求。zone id需要分配不同的管理域。
ZNS SSD的写模型也有多种:
1.单QD写入
最传统的写入方式,每个Zone限制一个IO的写入。
2.Append写入
在一个zone空间,队列Append写入多个数据。在队列CQ完成LBA映射刷新。适用大容量的写入场景。
3.跨zone的写入
每个zone的写入依然是要求QD1,主机有通过小容量zone管理数据放置的能力。主机可以看到zone id和zone group,主动权在host,对host的管理能力要求较高。
4.zone随机写区域
在最初的zone定义过程中,zone内部要求是顺序写入。随着应用需求的不断刷新,zns还新增了Zone随机写区域的功能。就是在Zone前面一个区域,设置可以随机写的区域,允许乱序写入,in-place刷新数据。相当于zone的一个缓存区。
从上面的应用场景和写入模型来看,不同场景下的ZNS SSD的配置完全不一样,市面上目前看到的ZNS SSD设置也是百花齐放,没有形成统一的格式。虽然都叫ZNS SSD,但是实际内部的NAND die的配置和管理方式都大相径庭。没有办法同一套软件适配所有的ZNS SSD,这样会让ZNS SSD生态建设受到限制。
ZNS SSD虽然有很大的优势,想要闯一片天地,依然需要多方面的努力。期待ZNS SSD可以早日实现美好的愿景。
精彩推荐:
-
Backblaze 2022 Q3 硬盘故障质量报告解读
-
漫谈云数据中心的前世今生
-
多维度深入剖析QLC SSD硬件延迟的来源
-
漫谈固态硬盘SSD全生命周期的质量管理
-
如何快速debug定位SSD延迟问题?
-
汽车存储SSD面临的挑战与机遇
-
超大规模云数据中心对存储的诉求有哪些?
-
SSD写放大的优化策略要统一标准了吗?
-
阿里云Optane+QLC存储实践案例分享
-
“后Optane时代”的替代存储方案有哪些?
-
浅析数据中心存储发展趋势
-
浅析PCIe链路LTSSM状态机
-
浅析Relaxed Ordering对PCIe系统稳定性的影响
-
实战篇|浅析MPS对PCIe系统稳定性的影响
-
浅析PCI配置空间
-
浅析PCIe系统性能
-
PLC SSD虽来但远,QLC SSD火力全开
-
Backblaze2022中期SSD故障质量报告解读
-
最全电脑固态硬盘SSD入门级白皮书
-
存储随笔《NVMe专题》大合集及PDF版正式发布!
-
加权循环仲裁WRR特性对NVME SSD性能有什么影响?
-
Linux NVMe Driver学习笔记之9: nvme_reset_work压轴大戏