ZNS的前世今生
Linux Turning Off The Light
Linux 内核5.15开始即将移除对LightNVM的支持(链接)，作为Open-Channel SSD的上层协议栈伙伴，皮之不存，毛将焉附，难道Open-Channel SSD就此走向灭亡了么？答案是否定的，因为Open-Channel进化出了更合适的协议----- Zoned Namespace, 下文简称ZNS
Zoned Storage
介绍ZNS SSD之前， 有必要介绍一下Zoned Storage（分区存储）, 其实ZNS SSD是Zoned Storage设备的一种实现 Zoned Storage设备是将address space分成多个zones, 不同于标准块设备的读写， Zoned Storage设备没有读限制但有写限制：必须顺序写，每个zone有一个write pointer去记录下一次要写的位置，数据不能覆写, 要写之前，必须先利用特别的命令进行擦除，这个限制几乎就是为NAND量身定制一样。
生态支持
-
一项技术的推广，离不开标准化，相较于独立的Open-Channel协议标准，ZNS加入了NVME2.0协议标准, 这样配合nvme协议的多namespace机制，比如一个namespace支持标准盘，另一个namespace支持ZNS。使nvme协议更多元同时， 也为用户提供了多重选择， 而不像Open-Channel SSD作为非标盘与标准盘很明显的界限
-
相较于Open-Channel SSD 相对单一的生态[上文提到的LightNVM], Zoned storage设备得到了Linux 生态更广泛的支持，设备驱动，文件系统，Device Mapper等多维度支持。下图为Zoned storage设备Linux内核IO协议栈。
-
硬件中除了基于Flash的SSD， SMR HDD(叠瓦式)也支持Zoned Storage, 传统硬盘与SSD结合 共享统一的协议栈，有利于数据中心的部署，更有利于存储发展
ZNS的优势
-
IO隔离
ZNS与Open-Channel一样，实现了IO分离
传统SSD，在host 以块设备形式暴露给主机，而在SSD内部FTL建立了LBA与物理NAND块的映射。因此NAND物理层面上并发性被屏蔽掉，故不能充分发挥NAND的并发性。数据的存放也是随机的，冷热数据不分，而Open-Channel SSD以及ZNS则直接将NAND物理地址或者并发单元暴露给主机。充分发挥NAND并发特性，并做到了应用隔离，提高了性能同时，并且可以做到更智能的数据存放
-
可预测的latency
传统SSD， 空盘性能与满盘性能差别非常大， 其主要原因是NAND颗粒，不能像内存一样覆写，而是必须先擦后写，所以在SSD内部有Garbage Collection(GC)流程， 当GC一旦启动时，性能会受影响。而GC流程又是对用户透明， 用户完全控制不了。而Open-Channel SSD以及ZNS是在host端建立FTL，以及直接运用文件系统， 离业务越近，业务更能根据持久化介质的特性，去做合适动作，保证性能同时，更保证了业务的QoS -
写放大更小
传统SSD，GC流程的引入，存在了写放大。虽然文件系统支持了Trim指令，但是依然不能彻底解决此问题， 写放大缩减了SSD的寿命，而基于ZNS以及Open-Channel的SSD在盘的视角来看没有写放大，或者说在整个IO协议栈流程中， 能够将写放大降低到比较小的程度 -
更小的TCO
传统SSD， 基本上满足1GB/1T的DRAM需求，对于一些消费级SSD， 虽然也存在Dram Less的形态，但是性能却有折扣，而Open-Channel SSD以及ZNS SSD则只需要更小的或者不需要Dram 资源。同时也不需要额外提供OP，降低了单盘造价。在颗粒的适配上也更简单，尤其是TLC与QLC差异上，传统SSD在处理上存在的不便，ZNS则能够很好避免。
ZNS应用场景
Zone Namespace SSD存在着诸多优势，但是也存在着消耗主机算力的天然弱点，但Open-Channel/ZNS之所以被选中，究其原因是: 传统存储IO协议栈存在着Log-on-Log现象， 即采用分层堆叠的IO协议栈，会在每一层加上元数据， 造成了写放大(见下图)。数据存放也由于分层抽象原因变得杂乱无章，每一层次GC的存在，更加剧了写放大。 一个IO从用户发起到最后存盘，那是波澜壮阔的一生链接，软件堆叠又总是寄希望于加入一个抽象层来解决扩展问题，但庞大的IO协议栈在现代SSD中已经出现了瓶颈， 通用性造成IO过五关斩六将，那么基于性能以及QoS的系统则希望IO能够单刀直入，这也是ZNS, 用户态驱动DPDK/SPDK能够磅礴发展的原因。比如说文件系统的日志模块，都是临时性的写入，存在极大的空间浪费。如果采用LSM-tree机制KV存储以及用户态日志型的文件系统诸如：LevelDB/RocksDB等 对接的是Zone Namespace SSD以及Open-Channel SSD，则可以做到将三层做聚合， 避免了不必要的日志产生， 提高了文件系统的性能同时，文件系统也可以有意识性地根据存储介质的特征，在适当时间启动GC， 保证了文件系统的QoS， 使业务运行更为平顺。
