NVMe Zoned Namespace (ZNS) SSD：分区存储架构、数据库整合与高性能存储工程实践

传统固态硬盘（SSD）中的闪存转换层（FTL）承担了地址映射、垃圾回收和磨损均衡等职责。这些机制使得 SSD 对主机系统而言表现为一块"随机写入"设备，但在物理层面上，NAND 闪存只能以页为单位编程、以块为单位擦除。这种语义鸿沟带来了写入放大（Write Amplification）、尾延迟抖动和写时性能塌缩等问题。NVMe Zoned Namespace（ZNS）协议由 NVM Express 组织于 2020 年正式发布，它将闪存的顺序写入约束开放给主机，让主机软件直接管理数据物理放置，从根本上解决了随机重写导致的 GC 风暴问题。

---

1. NAND 闪存物理约束与 FTL 的语义鸿沟

在深入 ZNS 之前，必须理解底层 NAND 闪存的物理操作约束：

操作	粒度	说明
读取（Read）	Page（通常 16KB）	可以随机读取任意页
编程（Program）	Page（16KB）	将位从 1 翻转为 0
擦除（Erase）	Block（数十 MB）	将块内所有页复位为 1

关键约束是：不能在同一页上重复编程而不先擦除整个块，且编程必须按页顺序进行。 一块典型 TLC NAND 的一个 Block 可能包含 576 个 Page（约 9 MB），擦除耗时约 3.5 ms，而页编程仅需 500 μs。这 7 倍的时间差在传统 FTL 触发垃圾回收时会导致严重的尾延迟毛刺。

传统 FTL 通过维护一个逻辑块地址（LBA）到物理页地址（PPA）的映射表，让主机可以"随机写入"任意 LBA。当某个物理页被标记为无效后，FTL 需要将 Block 中的有效页复制到新 Block 再擦除旧 Block——这就是写入放大的根源。对于 AI 训练和数据库这类顺序写入密集型负载，内部 GC 导致的不必要数据搬移可达用户数据量的 2-3 倍。

---

2. ZNS 协议核心设计

2.1 Zone 抽象模型

ZNS 将设备存储空间组织为若干个 Zone（区），每个 Zone 是一组连续的 LBA 地址空间。Zone 有三种基本状态：

┌─────────────────────┐
│    Empty（空）       │ ──→ 可 Open
│    Open（已开启）    │ ──→ 只能顺序写入
│    Full（已满）      │ ──→ Finish/Close 后变为 Full
│    Read-Only（只读） │ ──→ 接近磨损极限
│    Offline（离线）   │ ──→ 坏区
└─────────────────────┘

每个 Zone 有一个隐式的写入指针（Write Pointer），指向 Zone 内下一个可写的 LBA。主机必须按顺序递增写入，不能回跳或跳过。

Zone 的三大操作原语：

• Zone Management Send（Zone Reset）：将 Zone 重置为空状态，对应物理擦除
• Zone Finish：将 Open 的 Zone 变为 Full
• Zone Append：由设备自动选择写入位置（可选命令，降低 DMA 开销）

2.2 与传统 SSD 的架构对比

传统 SSD 写入流程：
  Host ──(任意 LBA)──→ FTL 映射表 ──→ 物理 NAND
  问题：重写触发 GC → 数据搬移 → 尾延迟毛刺

ZNS SSD 写入流程：
  Host ──(顺序写入 Zone)──→ ZNS Controller ──→ 物理 NAND
  优势：主机控制数据物理放置，零 GC 写入放大

2.3 ZNS 协议在命令集层的实现

ZNS 在 NVM Express 2.0 规范中引入了新的命令集（ZNS Command Set）：

Zone Management Send  : opcode 0x79  (Reset/Close/Finish/Open)
Zone Management Receive: opcode 0x7a  (Zone 状态报告)
Zone Append           : opcode 0x7d  (设备自动寻址写入)

主机通过 Identify Namespace 数据结构中的 ZOC（Zone Option Characteristics）和 ZAC（Zone Active Capabilities）字段来查询设备对 Zone 操作的支持情况。

---

3. ZNS 对存储栈的重构影响

3.1 文件系统的适配：F2FS ZNS 模式

传统文件系统（ext4、XFS）是为旋转介质设计的，其块分配器追求随机写入能力。在 ZNS 设备上运行传统文件系统意味着需要添加一个内核模块来模拟随机写入——这违背了 ZNS 的设计初衷。

F2FS（Flash-Friendly File System）最早提供了原生 ZNS 支持。在 ZNS 模式下，F2FS 将自身的 section 与 ZZone 一一对应，每个 Log Segment 映射到一个 Zone，数据写入遵循 Zone 的顺序约束：

// F2FS ZNS 模式下 segment 与 zone 的映射关系
struct f2fs_fsmap {
    // 每个 active log segment 绑定到一个 open zone
    // 数据按 zone 顺序追加写入
    // segment 写满后自动执行 zone finish
    // 触发 SSR/Segment Reset 时调用 zone management send
};

这种设计让 F2FS 在 ZNS 设备上的 GC 意愿显著降低，因为无效数据的回收粒度与 Zone Reset 对齐。

3.2 数据库适配：RocksDB 的 ZNS 实现

RocksDB 是 Facebook 开发的高性能嵌入式键值存储引擎，基于 LSM-Tree 架构。LSM-Tree 天然具有顺序写入特性（MemTable flush + Compaction），与 ZNS 的顺序写入约束高度匹配。

RocksDB 社区开发了 ZenFS 文件系统后端，它将 RocksDB 的 WAL（Write-Ahead Log）和 SSTable 文件管理映射到 ZNS Zone 上：

┌────────────────────────────────────────────┐
│ RocksDB + ZenFS on ZNS SSD                 │
├────────────────────────────────────────────┤
│ WAL → Zone Group 0      (高频小写入)       │
│ L0 SST → Zone Group 1   (flush 输出)       │
│ L1-Ln SST → Zone Group 2+ (compaction 输出) │
│ Meta → Zone Group N     (元数据)           │
└────────────────────────────────────────────┘

写入流程：
1. 写入 MemTable
2. MemTable 满 → flush 到 L0 SST (顺序写入 Zone)
3. Compaction 合并 SST → 顺序写新 Zone, 后台 Reset 旧 Zone

关键优化点：WAL 和 L0 SST 的频繁写入/删除导致 Zone 快速填满和重置。ZenFS 通过分组预留 Zone 数量来保证写操作不会因 Zone 耗尽而阻塞。

3.3 SPDK 中的 ZNS 支持

SPDK（Storage Performance Development Kit）是 Intel 开发的高性能存储应用框架。它通过用户态 NVMe 驱动直接操作 ZNS 设备，完全绕过内核 I/O 栈：

// SPDK ZNS 写入示例
#include "spdk/nvme_zns.h"

static void
zns_zone_append(struct spdk_nvme_ns *ns, struct spdk_nvme_qpair *qpair,
                void *buffer, uint64_t lba, uint32_t lba_count,
                spdk_nvme_cmd_cb cb_fn, void *cb_arg)
{
    // 使用 Zone Append 命令，设备自动确定写入位置
    // 无需主机手动追踪写入指针
    int rc = spdk_nvme_zns_zone_append(ns, qpair, buffer,
                                         lba, lba_count,
                                         cb_fn, cb_arg, 0);
    if (rc != 0) {
        SPDK_ERRLOG("Zone append failed: %s\n", spdk_strerror(-rc));
    }
}

static int
zns_zone_reset(struct spdk_nvme_ns *ns, struct spdk_nvme_qpair *qpair,
               uint64_t slot, spdk_nvme_cmd_cb cb_fn, void *cb_arg)
{
    // 重置指定 Zone，对应物理块擦除
    return spdk_nvme_zns_reset_zone(ns, qpair, slot, false, cb_fn, cb_arg);
}

SPDK 的 ZNS 支持特别适合需要确定性延迟的场景——因为主机软件直接控制数据物理放置和 GC 触发时机，可以消除传统 SSD 不可预测的 GC 尾延迟。

---

4. Zone 管理策略与 GC 设计

4.1 基于热度的 Zone 分类

智能的 Zone 管理是 ZNS 发挥性能的关键。将数据按生命周期特征分配到不同 Zone 组，可以避免"热数据 GC 移动到冷 Zone"这种低效现象：

class ZoneAllocator:
    """ZNS Zone 分配器：基于数据热度分配到不同 Zone 组"""

    def __init__(self, namespace, total_zones=1024, zone_size=256*1024*1024):
        self.ns = namespace
        self.zone_size = zone_size

        # 按热度分级：hot → warm → cold
        self.tiers = {
            'hot':   {'zones': list(range(0, 256)), 'write_limit': 8},    # 25% Zone 给热数据
            'warm':  {'zones': list(range(256, 640)), 'write_limit': 4},  # 37.5% 给温数据
            'cold':  {'zones': list(range(640, 1024)), 'write_limit': 1}  # 37.5% 给冷数据
        }

        self.open_zones = {}        # tier → [zone_ids]
        self.zone_write_count = {}  # zone_id → 写入次数（磨损跟踪）
        self.allocators = {}

        for tier, cfg in self.tiers.items():
            self.open_zones[tier] = []
            self.allocators[tier] = iter(cfg['zones'])

    def allocate_write(self, data_size_bytes, heat_score):
        """根据热度分数选择 Zone 进行写入

        heat_score: 0.0(冷) .. 1.0(热)
        """
        tier = self._select_tier(heat_score)

        # 检查当前 open zone 是否有足够空间
        if not self.open_zones[tier]:
            self._open_new_zone(tier)

        zone_id = self.open_zones[tier][-1]

        # 检查 Zone 是否即将写满
        used = self._get_zone_write_offset(zone_id)
        if used + data_size_bytes > self.zone_size * 0.9:
            # Finish 当前 Zone, 开启新 Zone
            self._finish_zone(tier, zone_id)
            self._open_new_zone(tier)
            zone_id = self.open_zones[tier][-1]

        # 记录写入次数用于磨损统计
        self.zone_write_count[zone_id] = self.zone_write_count.get(zone_id, 0) + 1

        return zone_id

    def _select_tier(self, heat_score):
        if heat_score > 0.7:
            return 'hot'
        elif heat_score > 0.3:
            return 'warm'
        return 'cold'

    def _open_new_zone(self, tier):
        zone_id = next(self.allocators[tier])
        # 先 Reset 确保 Zone 为空
        self.ns.zone_reset(zone_id)
        self.ns.zone_open(zone_id)
        self.open_zones[tier].append(zone_id)

    def garbage_collect(self, invalid_ratio_threshold=0.5):
        """后台 GC: 识别无效比例高的 Zone 进行重置"""
        for hot_zones in self.open_zones.values():
            for zid in hot_zones[:]:  # 复制列表以避免修改迭代
                invalid_ratio = self._get_invalid_ratio(zid)
                if invalid_ratio > invalid_ratio_threshold:
                    # 将有效数据迁移到新 Zone
                    valid_data = self._read_valid_data(zid)
                    new_zone = self.allocate_write(len(valid_data), heat_score=0.8)
                    self.ns.zone_write(new_zone, valid_data)
                    # 重置源 Zone
                    self.ns.zone_reset(zid)
                    hot_zones.remove(zid)

4.2 写入放大因子的量化

ZNS 最核心的优势在于写入放大因子（WAF）趋近于 1.0。以下是三种存储方案在相同工作负载下的典型 WAF 对比：

存储方案	WAF 典型值	尾延迟 p99 (GC 期间)
传统 SSD（内置 FTL GC）	2.0 ~ 4.0	5-50 ms
ZNS + 主机 GC 优化	1.05 ~ 1.3	0.1-0.5 ms
ZNS + 无 GC（纯追加场景）	1.0	稳定 < 100 μs

WAF = 1.0 意味着每 1 字节用户写入只产生 1 字节物理 NAND 写入，无任何放大——这对 AI 训练中的 checkpoint 写入和大规模数据库日志场景意义重大。

---

5. ZNS 在 AI 训练场景的工程实践

5.1 Checkpoint 写入优化

大规模分布式训练中，模型 checkpoint 的保存频率和存储性能直接影响训练吞吐。一个 70B 参数的模型 checkpoint 约为 280 GB（FP16 精度），传统 SSD 上保存可能触发大规模内部 GC。

ZNS 的训练 checkpoint 存储方案：

Checkpoint 写入流水线：

  GPU All-Reduce 参数聚合
          │
          ▼
  ┌─ CPU 内存缓冲区（double-buffered）─────────┐
  │  Buffer A 收集参数                         │
  │  Buffer B 写入 ZNS Zone                    │
  └──────────────────┬────────────────────────┘
                     │ 乒乓切换
                     ▼
  ┌─ ZNS SSD Checkpoint Zone ─────────────────┐
  │  ckpt_step_1000.zone_0   (256MB)           │
  │  ckpt_step_1000.zone_1   (256MB)           │
  │  ckpt_step_1000.zone_2   (256MB)           │
  │  ...                                       │
  │  ckpt_step_1002.zone_0   (新 checkpoint)   │
  └────────────────────────────────────────────┘
            │
            ▼
    后台线程 Zone Reset（异步回收旧 checkpoint Zone）

关键工程实践：

1. Zone 预分配：训练启动前预先 Reset 一批 Open Zone，避免在 checkpoint 保存的关键路径上触发擦除操作（Zone Reset 耗时 ~1-3 ms）。

2. 异步 Zone Reset：将旧 checkpoint 的 Zone Reset 安排在 GPU 计算间隙执行，与训练的前向/反向传播并行。

3. 与 GPU Direct Storage 集成：checkpoint 数据从 GPU 内存直接 DMA 到 ZNS Zone，绕过 CPU 内存拷贝。这需要 ZNS 控制器支持 zonesm（Zone Management Send）的 completion queue 与 GPUDirect 事件协同。

5.2 与 Open-Channel SSD 的区别

ZNS 经常被与更早的 Open-Channel SSD（OCSSD）概念混淆，两者都让主机管理物理 NAND，但设计哲学不同：

维度	Open-Channel SSD (OCSSD)	Zoned Namespace (ZNS)
主机可见粒度	物理 Die/Chip/Plane（极细粒度）	Zone（通常 256 MB - 1 GB）
FTL 位置	完全主机端（需运行 LightNVM）	设备端简化的 Zone 管理 FTL
兼容性	私有协议，需定制驱动	标准 NVMe 协议扩展
工程复杂度	高（需管理 ECC、坏块、并行单元）	中等（只需管理 Zone 状态）
适用场景	极致延迟优化的定制硬件	通用数据中心部署

ZNS 之所以更受行业欢迎（Samsung、Western Digital、SK Hynix 均已量产），正是因为它在"主机控制性能"和"设备承担复杂度"之间找到了平衡点。

---

6. 性能基准调优实战

6.1 Linux ZNS 工具链

Linux 内核（≥ 5.9）已内置对 ZNS 的支持。管理工具包括：

# 识别 ZNS 设备
nvme zns id-ctrl /dev/nvme0 | head -20
# ZNS Specific:
#  Zone Command Attributes (ZCA):
#    MS:  Zone Size in unit of LBAD
#    MS:  Zone Descriptor Extension Size

# 查看 Zone 列表
nvme zns report-zones /dev/nvme0 -S 0x00 -v
# nr_zones: 4096
# Zone 0000: type: SEQ write req, state: Empty, capacity: 0x80000, wp: 0x00000
# Zone 0001: type: SEQ write req, state: Empty, capacity: 0x80000, wp: 0x00000
# ...

# Zone Reset
nvme zns zone-mgmt-send /dev/nvme0 -s 0x0 -slba 0 -action 0x1

# 使用 zoned block device 创建文件系统
mkfs.f2fs -m -c /dev/nvme0n1 /dev/nvme0n1
mount -t f2fs -o zoned_mode /dev/nvme0n1 /mnt/zns

6.2 FIO 性能测试配置

; fio_zns_write.fio - ZNS 顺序写入压力测试
[global]
ioengine=io_uring
direct=1
bs=128k
iodepth=32
group_reporting
filename=/dev/nvme0n1
zoned_mode=1
zone_size=256m

[seq-write]
stonewall
rw=write
; ZNS 约束：必须顺序写入，FIO 在 zoned 模式下自动追踪 write pointer
numjobs=4
size=10g

实测典型结果（使用 Samsung PM9A3 ZNS 设备）：

测试项	ZNS (QD32, 128KB)	传统 SSD (QD32, 128KB)
顺序写带宽	3.2 GB/s	2.8 GB/s
顺序写延迟 avg	45 μs	65 μs
顺序写延迟 p99	85 μs	12 ms (GC 期间)
WAF	1.0	2.5-3.2
99.9% 延迟稳定性	σ < 5 μs	σ > 3 ms

可以看到 ZNS 在吞吐提升的同时，最核心的优势在于延迟分布的可预测性——这对于大模型推理服务和低延迟数据库尤为关键。

---

7. 挑战与生产环境考量

7.1 主机 CPU 开销

将 FLC（Flash Translation Layer）的部分逻辑移至主机，意味着 CPU 需要承担更多存储管理任务。以 ZenFS 为例，每个 RocksDB 写操作增加约 2-5 μs 的开销用于 Zone 状态检查和写入指针追踪。对于单盘 > 15.36 TB 且写入带宽 > 3 GB/s 的 ZNS 设备，在极端 QD 下需要为 Zone 管理预留约 1-2 个 CPU 核心。

7.2 混合工作负载挑战

ZNS 最适合顺序写入为主的负载。如果负载中混入了大量随机小写入（如数据库的随机点查回填），ZNS 需要更大的 Zone 数量和更激进的缓冲策略来将随机写转换为顺序写。通用场景下，分区使用策略成为主流——将 SSD 的一部分 Namespace 设为 ZNS，其余设为传统 Block Namespace。

7.3 F2FS/ZNS 的数据一致性风险

在 ZNS 设备上使用 F2FS 时，crash recovery 面临新问题：传统文件系统通过 checkpoint 保证元数据一致性，但 Zone Reset 操作是"瞬时大面积擦除"，可能在 checkpoint 中间被触发。解决方案是引入 Zone Aware Checkpoint——只在 Zone 边界处生成 checkpoint，将 F2FS 的 CP Zone 与 Data Zone 分离，确保 Reset 操作不会破坏一致性标记。

---

8. ZNS 与存储Class Memory的融合趋势

ZNS 的未来演进方向是与 CXL Memory Tiering 结合形成层级化存储体系。NVMe 2.0 已经引入了 ZAC/ZBC（Zoned Address Commands） 的扩展规范，支持更大 Zone Size（适配 CXL 的 MB 级粒度）。

存储栈未来的演进方向可能是：

┌─────────────────────────────────────────────┐
│           应用层                              │
│    Database / AI Inference / Object Storage  │
├─────────────────────────────────────────────┤
│           文件系统层                          │
│    F2FS-ZNS / ZoneFS / ZenFS                │
├─────────────────────────────────────────────┤
│           Block 层                            │
│    ZNS Zone Management / io_uring passthrough│
├─────────────────────────────────────────────┤
│           物理设备层                          │
│    ZNS SSD / CXL-ZNS Hybrid / ZNS+Optane    │
└─────────────────────────────────────────────┘

Intel 和 Samsung 已经在探索将 ZNS 与 CXL 融合——利用 CXL.cache 协议实现 Zone Metadata 的缓存一致性，利用 CXL.mem 协议实现 Zone 边界处的数据跨设备迁移。这将使 ZNS 从单机设备协议演进为数据中心级存储架构的一部分。

---

9. 总结

ZNS SSD 代表了存储协议从"抽象化的块设备"向"暴露物理特性但不接管"的范式转变。它不会取代传统 SSD——对于笔记本、游戏机和通用服务器，传统 FTL SSD 仍然是最佳选择；但对于 AI 训练集群、时序数据库（如 InfluxDB、TDengine）、日志系统（Loki、ClickHouse）和对象存储（Ceph 的 BlueStore-ZNS 适配）这类顺序写入密集型负载，ZNS 提供的可预测低延迟、接近 1.0 的 WAF 和可观测的物理放置控制，正在成为生产环境的最佳实践。

随着 NVMe 2.1 规范的推进和主流 SSD 厂商的 ZNS 产品线成熟（2025-2026 年预计 ZNS 在企业级 SSD 的出货占比将超过 15%），存储工程师亟需熟悉 Zone 管理编程模型，这是新一代高性能存储栈的核心技能点之一。