2 ZNS 架构
2.1 ZNS storage 模型演进
先大体看一下 ZNS-ssd 的内部数据分布：
ZNS-ssd 像 OC 那种 channel，将整个SSD内部的存储区域分为多个zone 空间，每一段zone空间管理一段LBA（物理page和逻辑地址之间的映射），不同的zone 空间之间的数据可以是独立的。最主要的是，每一个zone 内部的写入 只允许顺序写，可以随机读。因为 zone 内部的顺序写特性，基本可以消除 SSD GC的开销。为了保证zone 内部的顺序写，在ZNS内部想要覆盖写一段LBA地址的话需要先reset（清理当前地址的数据），才能重新顺序写这一段逻辑地址空间。
同时一个完整的 ZNS设备是支持完整的存储栈，包括底层的块驱动到上层的文件系统都是已经实现好的。这个完整的存储栈就是相比于OC-ssd的优势，能够对外屏蔽复杂的接入功能，紧抓用户的使用习惯，用户软件可以做到基本零成本接入。
当然，仅限于底层是顺序写的存储应用。rocksdb / ceph的bluestore 等。
整个存储栈的演进是一个过程，并不是直接就推出了ZNS的设计，下文将会详细介绍，从ZNS 的演进过程我们也能看到ZNS 可应用场景的一些限制。
2.1.1 zone storage model
最开始的时候西数推出了zone 形态的存储模型，也就是上图中SSD内部的存储空间按照zone 进行了逻辑划分，而且只允许顺序写，覆盖写的前提是reset 之前的LBA。
这个时候的zone storage model 内部实现 以及一些约束可以从以下几个方面来看：
1 Per-zone state machine
如果想要确定一个zone 是否能够写，需要通