OpenChannelSSD之六_从OpenChannelSSD到ZNS

背景

关于在GitHub上的Open Channel SSD 的开源项目好久没人更新过，在qemu搭建的平台上改进过，经常会出现bug, 对内核版本，qemu版本，系统版本要求相当高了。
虽然有很多论文已经发表出来了，但是讲真的觉得很多都是理论假设，并不能真的得到相应的实验结果，因此在学相关方面内容一定要看顶会论文，毕竟阿里的内部技术并不是公开的。

如今企业级要实现云存储效率需要单个SSD满足许多不同的工作负载，而工作负载现在可以说是无处不在。在应用共享SSD的时候，负载之间干扰造成延时忽高忽低，最坏时延迟巨幅升高。 保证为每一个硬盘用户提供稳定的服务质量，才能体现出云环境的服务质量。

传统SSD把内部的FTL交给主机处理是Open-Channel SSD的主要功能，让用户自制属于自己的SSD。

Chunk 和 PU

Open-Channel SSD提出了chunk和PU的概念。
Chunks特点：

• 在LBA范围内顺序写入;
• 需要重置才能重写;
• 借鉴HDD的SMR规范（ZAC / ZBC）;
• 针对SSD物理限制进行了优化:使写入与介质对齐
  

Parallel Units特点：

• Host可以对单独的工作负载进行direct I/O;
• 单个或者多个die实现条带化;
• 并行单元继承了底层介质的吞吐量和延迟特性;
• 与NVMe中的I / O确定性相似的概念;

不难看出，Open-Channel SSD实现了I/O分离，可预测性延迟的特点，FTL功能移至Host端负责数据管理以及I/O调度。
但是实际情况，Open-Channel Specification 仅仅定义了Open-Channel涉及的最为通用的部分。不同厂商的SSD产品特性不同，它们或者难以统一，对定制化应用和工作负载的需求，依旧欠缺灵活性

关于Zoned Namespaces (ZNS)

采用Open-Channel SSD架构有阿里，微软等，将这个架构成为NVMe标准规范一部分的概念，提供灵活的定制化需求是一个热点研究。西部存储将功能驱动到解决关键OCSSD用例的NVMe中，提出了ZNS的概念。

• 它是NVMe工作组中的技术提案

• 相对于正常的NVMe Namespace, Zoned Namespace将一个Namespace的逻辑地址
  空间切分成一个个的zone。Zone的基本操作有Read, Append Write，Zone
  Management 以及Get Log Page。

• 将zone接口标准化是为了：

• 减少设备端的WAF;
• 减少OP;
• 减少SSD的DRAM，这是SSD中代价最高的部分;
• 改善延迟和吞吐量;
• 适用软件生态系统；

怎么来理解?
ZNS与SMR的ZBC / ZAC相似
• 存储空间被分成多个zone
• 每一段zone内都是顺序写入的
• 它是针对SSD优化的接口
-与介质特征保持一致（Zone的大小和Nand的块大小一致，Zone的容量与介质大小一致）
-减少NAND介质擦除周期

关于Zone的信息：
• Zone 状态转换

• Empty, Implicitly Opened, Explicitly Opened, Closed, Full, Read Only, Offline
• Empty -> Open -> Full -> Empty -> ….
  • Zone Reset
• Full -> Empty
• Zone 大小 和 Zone容量
  • Zone 大小是固定的
  • Zone容量是在一个Zone内的可写区域
  • 与Open-Channel相比，最大的区别就是在Zoned Namespace中，Zone的地址是LBA（Logical Block Address, 逻辑块地址）Zone Namespace就可以避免Open-Channel里繁琐的
    各类地址转换。

考虑到对一个区域（zone）多个写入的可伸缩性低（如下图为例），ZAC/ZBC 需要严格的写入顺序，限制写入性能还会增加host的开销，因此，软件生态系统，HBA等面临巨大挑战。

所以引入追加区域 (Zone Append)，将数据追加到一个区域而不定义偏移量，由驱动器返回将数据写入该区域的位置。

Zone Write 示例：
3x Writes (4K, 8K, 16K) – Queue Depth = 1

Zone Append 示例：
3x Writes (4K, 8K, 16K) – Queue Depth = 3

ZNS 指的是具有ZAC / ZBC软件生态系统的Synergy。
现有的ZAC/ZBC-aware文件系统和设备映射都“工作正常”，支持ZNS只需要很少的更改；重用已应用于ZAC / ZBC硬盘驱动器（SMR）的现有工作；直接与文件系统集成（没有host-side FTL;1TB的介质设备不需要1GB 的DRAM; 能更好地利用SSD）；代码已经在大厂商生产中使用，并且可以在Linux生态系统中使用。

ZNS使用现有的存储堆栈：
• 用户空间库

• Libzbd
• Nvme-cli
• Blktests
• Util-linux (blkzone)
• fio
• libzns
  • 内核空间库
• NVMe对Zones的支持
• XFS, Btrfs, F2FS, dm-zoned, etc…
  • 具有ZNS支持的Qemu

ZNS是为了满足多数应用对QOS及Latency需求的基础，然而却不如Open-Channel灵活。