Linux Zoned Namespaces (ZNS) SSD 深度工程：从 NAND 闪存约束到存储栈重构

当 NAND 闪存的物理特性不再能被 FTL 黑盒掩盖时，ZNS SSD 提供了一种全新的"主机与设备协同"模型。本文从闪存物理约束切入，完整拆解 ZNS 协议、Linux 内核块层适配、文件系统协同、SPDK 用户态路径，以及与常规 SSD 的实测性能对比。

---

一、为什么需要 Zoning：闪存的物理约束

传统 SSD 通过 FTL（Flash Translation Layer）向主机呈现一个完全随机的块设备。所有闪存转换都在设备内部完成。这里有两个核心问题：

1.1 写放大（Write Amplification）

NAND 闪存必须擦除后才能写入，且擦除粒度（Block，通常 4-16MB）远大于写入粒度（Page，通常 16KB）。FTL 的垃圾回收（GC）需要搬移有效数据页，导致实际物理写入量远大于主机请求。

写放大系数 WAF = 实际闪存写入量 / 主机请求写入量。生产环境里，当前主流 NVMe SSD 的 WAF 通常在 2-8 之间，冷负载下甚至超过 10。

1.2 尾延迟与 QoS 不透明

FTL 在 GC 时会故意暂停主机 I/O，高负载下导致 P9999 延迟从 100µs 飙升到数十毫秒。更关键的是，主机完全无法预测设备何时进入 GC 状态——这种随机抖动对分布式存储系统是致命的。

ZNS SSD 的思路是把"区域"（Zone）概念暴露给主机，让主机自己管理哪些区域可写、哪些不可写，从而消除设备侧隐藏的 GC。

---

二、ZNS 协议架构：NVMe 2.0 上另一种设备形态

ZNS 是 NVM Express 组织在 NVMe 2.0 规范中定义的扩展命令集。它引入两种核心概念：Zone 和 Zone 状态机。

2.1 Zone 核心概念

• Zone：一个连续的 LBA 区域，通常大小为 256MB 或 1GB（可通过 Identify Namespace 查询）。
• Zone 类型：
• 常规 Zone（Conventional Zone）：任意读写，兼容传统模式——但为了推迟垃圾回收准备。
• 顺序写入 Zone（Sequential Write Required, SWR）：必须按顺序写入，禁止随机写或跳过写。
• 联机 Zone（Online）：设备运行时可直接操作其状态。

2.2 Zone 状态机

每个 Zone 处于七个状态之一：

Empty → Explicit Open → Full/Closed → Offline
  ↑________↓___________________↓
          (Reset 或 Finish 命令回退)

各状态含义：

状态	含义
Empty	空闲，未写入任何数据
Explicit Open	主机显式使用 Zone Management Send 打开该 Zone，Open 需要 Write Pointer 单调递增
Implicit Open	主机对 Empty Zone 首次写入自动打开
Closed	主机关闭但仍可写
Full	写满，自动进入
Read Only	只读
Offline	离线，故障或坏块

Write Pointer（写指针）：记录该 Zone 下一个合法的写入 LBA。顺序写必须从 WP 开始，且每次写入长度不能超过 Zone 末尾。

2.3 ZNS 关键命令

命令	Opcode	功能
Zone Management Send	0x79	对 Zone 发送动作（Open/Close/Finish/Reset等）
Zone Append	0x7D	追加写入，无需传递 SLBA，返回写入位置
Zone Management Receive	0x7A	查询 Zone 描述符

Zone Append 是 ZNS 的高性能命令：主机无需锁竞争，直接发起追加写，设备自动找到最长的连续空闲头并返回 LBA。这在多客户端并发写入场景下避免了锁竞争。

---

三、Linux 内核 ZNS 支持：从块层到底层

ZNS 的 Linux 支持自 5.9 引入，后续版本持续完善。核心改动在块层、I/O 调度器和文件系统三个层面。

3.1 块层块设备接口

ZNS 设备暴露为 /dev/nvmeXnY，但通过 BLK_ZONE 相关 ioctl 暴露 Zone 信息：

#include <linux/blkzoned.h>

struct blk_zone_report {
    __u64 sector;
    __u64 nr_zones;
    __u32 flags;       // 报告类型：全部 / 仅常规 / 仅顺序
    __u64 reserved[2];
    struct blk_zone entries[];
};

struct blk_zone {
    __u64 start;       // LBA 开始
    __u64 len;         // LBA 长度
    __u64 wp;          // 写指针位置
    __u8  type;        // BLK_ZONE_TYPE_*
    __u8  cond;        // BLK_ZONE_COND_*
    __u8  non_seq;     // 是否非顺序写
    __u8  reset;       // 建议重置
    __u8  reserved[36];
};

常用获取 Zone 列表的代码框架：

int fd = open("/dev/nvme2n1", O_RDWR);
struct blk_zone_report report = {0};
report.sector = 0;
report.nr_zones = 4096;   // 缓冲区大小

if (ioctl(fd, BLKREPORTZONE, &report) < 0) {
    perror("BLKREPORTZONE failed");
    return -1;
}

for (int i = 0; i < report.nr_zones; i++) {
    struct blk_zone *z = &report.entries[i];
    printf("Zone %d: start=%llu, len=%llu, wp=%llu, type=%d, cond=%d\n",
           i, z->start, z->len, z->wp, z->type, z->cond);
}

3.2 I/O 调度器适配

传统 I/O 调度器（如 BFQ、mq-deadline）基于"任何 LBA 均可随机写"的假设，会进一步合并重排请求。但 ZNS 的 SWR Zone 要求顺序写入，因此 I/O 调度器必须感知 Zone 边界。

Linux 6.x 后： - mq-deadline 增加了 ELEVATOR_QUEUE_FLAG_ZONED，在调度时维护 Zone 顺序不变。 - BFQ 类似，对 SWR Zone 禁止跨 Zone 重排。 - None（Noop） 调度器在 ZNS 上反而往往是生产推荐：让应用完全控制 I/O 顺序，设备内部已是 SLC/MLC 硬件顺序追加路径。

典型 ZNS 设备的默认调度器设置为 none：

echo none > /sys/block/nvmeXnY/queue/scheduler

3.3 Zone Capacity 与 Zone Size 的区别

较新的 ZNS 设备支持 Zone Capacity < Zone Size。物理闪存擦除块可能大于逻辑 Zone，两者差异由 Zone Capacity 值决定：

• Zone Size：Zone 的 LBA 范围长度
• Zone Capacity：Zone 最大可写 LBA 数（≤ Zone Size）

这允许设备内部预留一部分空间用于 SLC/TLC 模式动态转换，同时在逻辑上仍然满足 1:1 顺序写入约束。

3.4 块层自动处理

内核块层自动维护： - WP 跟踪：每次写入后，框架自动更新 WP 位置，通过 BLK_ZONE_seq 标志识别 Zone。 - 写入顺序保证：如果用户尝试非顺序写（WP 前 LBA），块层直接返回 EINVAL。 - Zone Reset 原子性：BLKRESETZONE ioctl 原子清空 Zone WP=0。

---

四、文件系统与 ZNS：F2FS Zone 模式与 ZoneFS

传统文件系统（ext4、XFS）基于随机写入设计，直接跑在 ZNS 内 Layer 无效。Linux 提供了两种 ZNS 文件系统方案。

4.1 F2FS Zone Mode

F2FS（Flash-Friendly File System）原生支持 Zone 设备。5.13 引入的 zoned 挂载选项启用 Zone-aware 特性：

# 创建 F2FS 并强制 Zone 模式
mkfs.f2fs -m -o 4096 /dev/nvme2n1    # -m 启用 multi-head logs
mount -t f2fs /dev/nvme2n1 /mnt/zns \
  -o zoned_mode=1,active_logs=6

F2FS 将每个 Zone 映射为一个段组（Segment）： - 热数据写入到 Regular Zone 的 SLC 缓存层（设备内部 Slater cache） - 冷数据自动迁移到 SWR Zone - GC 由文件系统主导，设备不再承担后台数据搬移

4.2 ZoneFS

ZoneFS 是 Linux 5.9 引入的极简文件系统：直接将每个 ZNS Zone 映射为一个普通文件。没有 inode 缓存、没有日志、没有目录结构。

mount -t zones /dev/nvme2n1 /mnt/zones
ls /mnt/zones/
# zone0  zone1  zone2  ...

每个文件对应一个 Zone，打开即可顺序追加写。ZoneFS 适合需要自己实现 GC 逻辑的场景（如自定义 LSM-Tree）。

ZoneFS 的核心价值：让应用直接看到闪存物理边界，配合 SPDK 可以实现用户态 ZNS 存储引擎。

---

五、SPDK 用户态 ZNS 路径：从 NVMe Passthrough 到用户态Zone子系统

SPDK（Storage Performance Development Kit）从 19.10 版本开始支持 ZNS，通过用户态 NVMe 驱动绕过内核，实现零拷贝 I/O。

5.1 架构层次

┌─────────────────────────┐
│     SPDK ZNS Bdev       │  ← 块设备抽象层（可选）
├─────────────────────────┤
│   NVMe ZNS Driver       │  ← 用户态 Zone 跟踪 + command 封装
├─────────────────────────┤
│   用户态 NVMe vfio/msix │  ← UIO/VFIO 驱动
└─────────────────────────┘
         PCIe
    ┌──────────┐
    │  ZNS SSD │
    └──────────┘

5.2 初始化代码示例

#include "spdk/nvme.h"
#include "spdk/nvme_zns.h"

static void
zns_cb(void *arg, const struct spdk_nvme_cpl *cpl)
{
    if (spdk_nvme_cpl_is_error(cpl)) {
        fprintf(stderr, "ZNS command failed\n");
        return;
    }
    printf("Zone management OK\n");
}

int main(int argc, char **argv)
{
    struct spdk_nvme_ctrlr *ctrlr;
    struct spdk_nvme_ns *ns;
    struct spdk_nvme_zns_ns_data *ns_data;

    // SPDK 环境初始化
    spdk_env_init(&(struct spdk_env_opts){.name = "zns_demo"});

    // 探测 NVMe 设备
    if (spdk_nvme_probe(NULL, NULL, NULL, NULL, NULL) != 0) {
        return -1;
    }

    ctrlr = spdk_nvme_get_first_ctrlr();
    ns = spdk_nvme_ctrlr_get_ns(ctrlr, 1);

    // 检查是否支持 ZNS
    ns_data = spdk_nvme_zns_ns_get_data(ns);
    if (!ns_data->mar && !ns_data->mor) {
        printf("Namespace supports zone management\n");
    }

    // 查询第一个 Zone 的 WP
    uint64_t zone_id = 0, wp = 0;
    spdk_nvme_zns_ns_get_zone_wp(ns, zone_id, &wp);
    printf("Zone 0 WP: %lu\n", wp);

    return 0;
}

5.3 写入数据到 SPDK ZNS Zone

void
seq_write_to_zone(struct spdk_nvme_ns *ns, uint64_t zslba,
                  void *buf, uint32_t size)
{
    struct spdk_nvme_qpair *qpair = spdk_nvme_ctrlr_alloc_io_qpair(ctrlr, NULL, 0);

    // ZNS 必须顺序写入
    spdk_nvme_zns_ns_zone_append(ns, qpair, buf, size,
                                  zslba,    // Zone 起始 LBA
                                  0,        // 不跨 Zone
                                  zns_cb,   // 完成回调
                                  NULL);    // 回调参数
}

SPDK 的 ZNS 模块在内部维护 WP 跟踪，用户无需反复查询设备状态，仅需传递 Zone SLBA，SPDK 自动回调归位到正确位置。

---

六、ZNS vs 常规 SSD：写放大、延迟与 TCO 实测

6.1 写放大对比

业界多家测试表明：随机写场景下，ZNS SSD WAF 接近 1.0，而常规 SSD 可达 5-9。原因是 ZNS 设备只做顺序追加，不做 GC。

工作负载	常规 SSD WAF	ZNS SSD WAF
随机写 16KB	4.2±1.8	1.0-1.1
4K 随机写	8.5±3.0	1.01
混合读写 7:3	2.1	1.05
顺序写 1MB	1.0	1.0

6.2 尾延迟对比

常规 NVMe SSD P9999 延迟： - 空闲态：~80µs - 高载态：~15-40ms（GC 影响）

ZNS SSD P9999 延迟： - 空闲态：~60µs（略优，走纯顺序路径） - 高载态：~90µs（无 GC 抖动）

6.3 TCO 优势

SSD 写入寿命以 TBW（Terabytes Written）计量。WAF=5 代表：

主机写入 1TB → 实际闪写 5TB → 消耗 5TB 寿命

若 ZNS WAF=1.1：

主机写入 1TB → 实际闪写 1.1TB → 节省近 80% 寿命

2.5 英寸 32TB ZNS SSD 在擦写次数（P/E cycles）上等效于常规 SSD 的 4 倍以上。在云存储集群中，每块 ZNS SSD 可减少 1/3 的替换频率。

---

七、在分布式系统中适配 ZNS：以 Ceph 为例

Ceph 的 Bluestore 在设计上更适合 ZNS：

特性	传统 SSD	ZNS SSD 适配
WAL/DB 分离	多盘并发 GC	WAL 独占 Zone，读写均顺序
数据池	BlueFS 随机写	ZNS Zone-aware 分配器
GC 触发	后台碎片回收	应用层 Zone Reset
RocksDB 优化	读写放大	ZNS 写放大极低，降低 compaction

实际 Ceph Bluestore on ZNS 改造路径： 1. BlockDevice 抽象实现 ZonedBlockDevice，每个 PG 写入一个 Zone 2. BlueFS 元数据集中放在 Conventional Zone 3. WAL 复用 SPDK 高速路径顺序写入 4. 交易提交时 Zone Finish 确保原子性

---

八、Who Should Not Use ZNS（不适合的场景）

ZNS 不是银弹。以下场景仍然更适合传统 SSD：

纯随机读：没有写顺序化要求，FTL 隐藏的 GC 开销不明显。ZNS 的 SLC 缓存较小（因不允许设备侧随机缓存写入回写），读密集场景可能不如常规 SSD。

小数据量写入：ZNS 以 Zone（256MB+）为最小写入管理单元。日志类持续微写入需要应用层 Buffer Zone，引入复杂度。

强一致性场景的挑战：ZNS 顺序写无法原地更新 LSM-Tree / B+ 树 leaf 节点，必须配合 Zone Reset + Batch Write 模式，这要求文件系统或存储引擎重写数据路径。

协议兼容性问题：早期 Linux 内核（<5.10）与某些 RAID 卡固件存在 ZNS 元数据包不对齐，导致部分设备无法识别 Reset 信号。生产环境至少选择 5.15 以上 LTS 内核。

---

九、2026 年 ZNS 生态现状

• 主流云厂商：微软 Azure、AWS、阿里云均已支持 ZNS 实例（AWS io2 Block Express ZNS 变体）
• 开源 ZNS SSD 模拟器：QEMU 6.1+ 内置 NVMe ZNS 支持，可在无硬件环境下测试 SPDK 应用
• ZNS 工具链：nvme-cli 里的 zone 子命令、zonefs-tools、SPDK 23.05 完整 ZNS 子系统
• Linux 6.x 路线图：chunk_zone 支持大规模 Zone 自动分配、ZNS 与 io_uring 集成加速 Reg fd 路径

---

十、写在后面

ZNS 是 NVMe 生态向"应用定义存储"演进的重要里程碑。它不是在消灭 FTL，而是把 FTL 放到合适的位置：只负责 SLC 缓存、ECC 纠错、坏块替换。主机层获得了对闪存物理布局的可见性，配合 SPDK 用户态驱动和 Zone-aware 文件系统，可以做到延迟降低 10 倍以上。

如果你在做存储引擎、日志系统、LSM-Tree 优化，低延迟、零 GC 抖动的 ZNS 是下一步最值得投入的方向——尽早开始 QEMU ZNS 模拟器验证，准备好迎接 2026 年后 ZNS SSD 全面普及的技术拐点。