引言

在上次存储随笔更新了一篇文章“炙手可热的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命令成功后的状态
• ImplicitlyOpened：对处于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带来的负面效应就是写带宽下降、读延迟升高、使用寿命下降等问题。

扩展阅读：写放大

在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可以早日实现美好的愿景。