NVMe命名空间管理与LBA格式配置深度解析（Namespace与Format NVM全流程）

摘要：深度解析NVMe命名空间（Namespace）架构模型、LBA格式（LBAF）选择、Format NVM命令全流程、命名空间创建/删除/挂载生命周期，结合NVMe 2.0规范多命名空间增强、AER异步事件、Identify数据结构，附Linux内核nvme-core源码与nvme-cli实测操作指南。

目录

• 一、NVMe命名空间架构模型全景
• 二、LBA格式（LBAF）与元数据布局
• 三、Format NVM命令详解与执行模型
• 四、命名空间创建、删除与Attach生命周期
• 五、NVMe 2.0多命名空间与共享Namespace增强
• 六、Linux内核nvme-core命名空间管理源码分析
• 七、nvme-cli命名空间操作实战与格式化性能测试
• 八、命名空间安全擦除与数据销毁机制
• 九、当日知识点小结
• 十、思考题
• 参考资料

一、NVMe命名空间架构模型全景

1.1 从LUN到Namespace的范式升级

在SCSI/SAS架构中，存储设备通过LUN（Logical Unit Number）对上层暴露多个逻辑卷；而在NVMe架构中，对应的抽象是Namespace（命名空间）。但Namespace远不止是"换个名字的LUN"——它在协议层面被重新设计，带来了数量级的性能与管理能力提升。

┌──────────────────────────────────────────────────────────────────────────┐
│ SCSI LUN vs NVMe Namespace 架构对比 │
├──────────────────────────────┬───────────────────────────────────────────┤
│ SCSI LUN │ NVMe Namespace │
├──────────────────────────────┼───────────────────────────────────────────┤
│ 最大65535个LUN/目标 │ 最大4294967294个NS (NSID 0xFFFFFFFE) │
│ 通过Report LUNs命令枚举 │ 通过Identify NS列表枚举 │
│ 每个LUN独立SCSI命令集 │ 每个NS共享Admin Queue，独立IO Queue │
│ LUN Masking在控制器外部实现 │ Namespace Management在控制器内原生实现 │
│ 格式化需SCSI Format Unit │ Format NVM原生命令，支持Secure Erase │
│ 元数据通过Mode Page配置 │ LBA Format在Identify中静态声明 │
└──────────────────────────────┴───────────────────────────────────────────┘

规范原文：NVMe 2.0b Section 6.1.1 — “A namespace is a quantity of non-volatile memory that may be formatted into logical blocks. A controller may support up to 2^32 – 1 namespaces.”

1.2 Namespace ID（NSID）空间划分

NVMe使用32位NSID标识命名空间，地址空间经过精心设计：

关键数据：虽然理论支持42亿个命名空间，但企业级SSD实际支持的NS数量通常在 16~64 之间（如三星PM9A3支持32个NS，Intel P5520支持64个NS），主要受FTL表项、控制器SRAM、队列资源限制。

1.3 Controller-Namespace 关系模型

NVMe规范定义了三种Controller与Namespace的关联模型：

模型A：单控制器多命名空间（最常见，消费级/入门企业级）
┌─────────────────────────────────┐
│ NVMe Controller │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ NS 1 │ │ NS 2 │ │ NS 3 │ │
│ └──────┘ └──────┘ └──────┘ │
│ Admin + I/O Queues │
└─────────────────────────────────┘

模型B：多控制器共享命名空间（双端口企业级，高可用场景）
┌───────────────┐ ┌───────────────┐
│ Controller 1 │ │ Controller 2 │
│ Admin Queue │ │ Admin Queue │
│ I/O Queues │ │ I/O Queues │
└───────┬───────┘ └───────┬───────┘
│ Shared Namespace │
▼ ▼
┌────────────────────────────────────────┐
│ NS 1 (NSID = 1, shared) │
│ NS 2 (NSID = 2, shared) │
└────────────────────────────────────────┘

模型C：多控制器独立命名空间（NVMe 2.0 MV虚拟化）
┌─────────────────────────────────────┐
│ Primary Controller (PF) │
│ ┌───────────┐ ┌───────────┐ │
│ │ Secondary │ │ Secondary │ … │
│ │ Ctrl #1 │ │ Ctrl #2 │ │
│ │ NS1/NS2 │ │ NS3/NS4 │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────┘

模型B是企业级双端口SSD的标准架构，支持主机级冗余；模型C是NVMe 2.0引入的原生虚拟化能力，每个Secondary Controller拥有独立的命名空间集合与队列资源。

二、LBA格式（LBAF）与元数据布局

2.1 LBA Format 数据结构定义

每个NVMe SSD的Identify Namespace数据结构中包含16个预定义的LBA Format（LBAF 0~15），每个格式描述一种LBA大小与元数据大小的组合。

Identify NS LBA Format 结构（NVMe 2.0b Figure 252）：

struct nvme_lbaf {
__le16 ms; // Metadata Size (元数据字节数)
__u8 ds; // Data Size (LBA数据大小 = 1 << ds 字节)
__u8 rp; // Relative Performance（相对性能评级）
#define NVME_LBAF_RP_BEST 0x0 // 最佳性能
#define NVME_LBAF_RP_BETTER 0x1 // 更好
#define NVME_LBAF_RP_GOOD 0x2 // 良好
#define NVME_LBAF_RP_DEGRADED 0x3 // 降级
#define NVME_LBAF_RP_MASK 0x3
};

其中ds字段是关键：LBA数据大小 = 2^ds 字节。常见值：

• ds = 9 → 512字节（传统扇区大小）
• ds = 12 → 4096字节（4K扇区，高级格式化）

规范原文：NVMe 2.0b Section 5.15.2.3 — “The data size is 2^ds bytes. The minimum value of ds is 9 (i.e., minimum LBA data size is 512 bytes).”

2.2 常见LBA Format组合

以三星PM9A3 3.84TB企业级SSD为例，Identify返回的LBAF列表：

使用nvme-cli查看实际设备支持的LBAF：

$ nvme id-ns /dev/nvme0n1 –lbaf
lbaf 0 : ms:0 lbads:9 rp:0x0 (in use)
lbaf 1 : ms:8 lbads:9 rp:0x1
lbaf 2 : ms:0 lbads:12 rp:0x0
lbaf 3 : ms:8 lbads:12 rp:0x1

2.3 元数据（Metadata）的三种承载方式

元数据是伴随每个LBA的额外数据，主要用于端到端数据保护（E2E Data Protection，DIF/DIX）。NVMe规范定义了三种元数据承载方式：

方式A：元数据在独立Buffer中（Metadata as separate buffer）
┌───────────────────────┐ ┌──────────┐
│ Data (4096 bytes) │ │ Meta (8B)│
└───────────────────────┘ └──────────┘
PRP1/PRP2 MPTR

方式B：元数据在Data Buffer末尾（Metadata at end of data buffer）
┌──────────────────────────────────────┐
│ Data (4096 bytes) │ Meta (8B) │
└──────────────────────────────────────┘
PRP1/PRP2 （连续存放）

方式C：扩展元数据（Extended Metadata，64B/128B）
┌───────────────────────────────────────────────────────┐
│ Data (4096B) │ Guard(2B) │ AppTag(2B) │ RefTag(4B) │
│ │ │ │ │ ← 8B DIF标准
│ │+ 厂商私有域(如LDPC校验、时间戳等) │ ← 扩展56B
└───────────────────────────────────────────────────────┘

厂商白皮书：根据美光2024年《7450 MAX SSD Product Brief》，64B扩展元数据模式可支持每LBA携带完整的PI信息+厂商私有纠错域，但LBA有效容量下降约1.56%，随机写性能下降约12%~18%。

2.4 4K Native vs 512e 的性能差异

512e（512字节模拟）模式下，SSD内部仍然是4K物理页，但对外模拟512字节逻辑扇区。这导致了著名的**读-修改-写（Read-Modify-Write, RMW）**问题：

写操作路径对比：

512e模式写入512B：
┌─────────────────────────────────────────────┐
│ 1. 读取整个4K物理页到缓存 │
│ 2. 修改512B子扇区内容 │
│ 3. 重新计算ECC校验码 │
│ 4. 写入完整4K页（触发擦写周期） │
│ 5. 更新FTL映射表 │
└─────────────────────────────────────────────┘
→ 写放大系数 = 8x（数据量），延迟 = 4K读 + 4K写

4K原生模式写入4K：
┌─────────────────────────────────────────────┐
│ 1. 直接写入4K数据 │
│ 2. ECC硬件计算（与写入并行） │
│ 3. 更新FTL映射表 │
└─────────────────────────────────────────────┘
→ 写放大系数 = 1x，延迟 = 4K写

性能量化对比（三星PM9A3 3.84TB，4K随机写，QD=32）：

实测数据：来自SNIA 2024 Storage Developer Conference报告，4K原生模式相比512e模式，随机写性能提升约17%，P99延迟降低约20%，WAF降低约25%。

三、Format NVM命令详解与执行模型

3.1 Format NVM 命令数据结构

Format NVM是Admin命令（Opcode 0x80），用于对指定命名空间进行低级格式化，可改变LBA格式、启用元数据保护、执行安全擦除。

Format NVM 命令格式（NVMe 2.0b Figure 98）：

struct nvme_format_nvm_cmd {
__u8 opcode; // 0x80 (Format NVM)
__u8 flags; // FUSE (bits 1:0)
__u16 cid; // Command ID
__le32 nsid; // Namespace ID
__le64 reserved1[2];
__le64 mptr; // Metadata Pointer (保留)
__le32 dword10;
#define NVME_FMT_LBAF_SHIFT 0 // bits 3:0 – LBA Format
#define NVME_FMT_LBAF_MASK 0xF
#define NVME_FMT_MS_SHIFT 4 // bit 4 – Metadata Setting
#define NVME_FMT_MS_MASK 0x1
#define NVME_FMT_SE_SHIFT 5 // bits 7:5 – Secure Erase Setting
#define NVME_FMT_SE_MASK 0x7
#define NVME_FMT_SE_NO_SE 0x0 // 不执行安全擦除
#define NVME_FMT_SE_USER 0x1 // 用户数据擦除
#define NVME_FMT_SE_CRYPTO 0x2 // 加密擦除
#define NVME_FMT_PI_SHIFT 8 // bits 10:8 – Protection Information
#define NVME_FMT_PI_MASK 0x7
#define NVME_FMT_PIL_SHIFT 11 // bit 11 – PI Location
#define NVME_FMT_DULBE_SHIFT 12 // bit 12 – Deallocate Unwritten LB
#define NVME_FMT_DRM_SHIFT 16 // bits 18:16 – DSM Range Management
__le32 dword11;
__le32 dword12;
__le32 dword13;
__le32 dword14;
__le32 dword15;
};

3.2 Secure Erase Setting 三级安全擦除

Format NVM支持三级安全擦除（Secure Erase Setting）：

三级安全擦除数据销毁对比：

FTL重置 (SES=0)：
物理NAND ───────► 数据完整保留 ◄────── 可通过数据恢复工具读取
│
FTL映射表被清空

用户数据擦除 (SES=1)：
物理NAND ───────► 全部块擦除为0xFF ◄── 物理上无有效数据
│
FTL映射表重建

加密擦除 (SES=2)：
物理NAND ───────► 数据仍加密存在 ◄── 但密钥已销毁，无法解密
│
DEK (Data Encryption Key) 被删除

规范原文：NVMe 2.0b Section 5.1.3 — “If Cryptographic Erase is selected, the controller shall delete all encryption keys associated with the user data. After this operation, the user data is no longer accessible even if a subsequent read of the NAND media is performed.”

3.3 Format NVM 执行状态机

Format NVM是一个长耗时命令，规范允许控制器在执行期间返回"命令仍在处理中"状态，主机通过AER或Get Log Page轮询进度。

Format NVM 执行状态机：

┌─────────────┐
│ Idle/Ready │
└──────┬──────┘
│ 收到Format NVM命令
▼
┌─────────────┐
│ Preparing │ 验证参数、锁定Namespace
└──────┬──────┘
│
▼
┌─────────────┐
│ Formatting │ 主格式化阶段
│ (Progress) │ 进度可通过Format NVM Progress Log读取
└──────┬──────┘
│
┌──────┴──────┐
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ Success │ │ Failed │
└────┬────┘ └────┬────┘
│ │
▼ ▼
AER通知完成 AER通知错误（写错误日志）

Format NVM Progress Log（Log Identifier 0x81）结构：

struct nvme_format_nvm_progress_log {
__u8 status;
#define NVME_FMT_PROG_IDLE 0x0 // 空闲
#define NVME_FMT_PROG_IN_PROGRESS 0x1 // 进行中
#define NVME_FMT_PROG_SUCCESS 0x2 // 成功完成
#define NVME_FMT_PROG_FAILED 0x3 // 失败
__u8 reserved[3];
__le32 percentage_remaining; // 剩余百分比（0~100）
// …
};

3.4 格式化对FTL的影响

不同的Format模式对SSD内部FTL的影响程度不同：

关键洞察：SES=0的"快速格式化"实际上只是擦除了FTL映射表，NAND上的数据原封不动。这也是为什么数据恢复公司可以从格式化后的SSD中恢复数据——只要NAND颗粒没有被物理擦除。

四、命名空间创建、删除与Attach生命周期

4.1 Namespace Management 命令

NVMe规范提供了完整的命名空间管理Admin命令集：

Namespace Management 命令（创建/删除命名空间）：

struct nvme_ns_management_cmd {
__u8 opcode; // 0x0D (Namespace Management)
__u8 flags;
__u16 cid;
__le32 nsid; // 创建时填0，删除时填目标NSID
__le64 reserved1[2];
__le64 mptr;
// dword10: Select (低4位)
__le32 sel;
#define NVME_NS_MGMT_CREATE 0x0 // 创建命名空间
#define NVME_NS_MGMT_DELETE 0x1 // 删除命名空间
// …
};

4.2 创建命名空间全流程

创建一个新的命名空间涉及以下完整流程：

步骤1：发送 Namespace Management (Create) 命令
│
▼
步骤2：控制器验证参数（容量、LBAF、NSID等）
│ 校验：容量是否足够？LBAF是否支持？NSID是否冲突？
▼
步骤3：分配FTL映射表区域
│ 在DRAM/SRAM中分配映射表空间
▼
步骤4：分配NAND物理空间
│ 从OP或未分配空间中划出指定容量
▼
步骤5：Namespace Attachment (Attach)
│ 将新建的NS绑定到指定Controller
▼
步骤6：AER通知完成
│ 发送"Namespace Attribute Changed"异步事件
▼
步骤7：主机重新扫描命名空间
│ nvme rescan
▼
新设备节点 /dev/nvmeXnY 出现

创建命名空间的nvme-cli命令示例：

# 查看控制器支持的最大命名空间数
$ nvme id-ctrl /dev/nvme0 | grep nn
nn : 32

# 查看现有命名空间容量
$ nvme list
Node SN Model Namespace Usage Format FW Rev
——————— ——————– —————————————- ——— ————————– —————- ——–
/dev/nvme0n1 S69SNE0TB00000 SAMSUNG MZQL23T8HCLS-00A07 1 3.84 TB / 3.84 TB 512 B + 0 B GDC5602Q

# 创建一个新的命名空间（需要支持Namespace Management）
# 参数：容量(字节)、LBA格式、NSID（可选）
$ nvme create-ns /dev/nvme0 –nsze=200000000 –ncap=200000000 –lbaf=2 –flbas=0
Success creating namespace: nsid=2

# 将命名空间附加到控制器
$ nvme attach-ns /dev/nvme0 –namespace-id=2 –controllers=0x1
attach ns:2 success, ctrl list updated

# 重新扫描
$ nvme rescan /dev/nvme0

4.3 删除命名空间的注意事项

删除命名空间是不可逆操作，但规范要求控制器遵循以下安全规则：

警告：在支持Namespace Management的企业级SSD上，删除命名空间是快速操作（秒级），因为只是释放FTL表项和容量配额，物理数据并未擦除。敏感数据必须先执行安全擦除。

五、NVMe 2.0多命名空间与共享Namespace增强

5.1 NVMe 2.0 命名空间相关新特性

NVMe 2.0规范（2021年发布）在命名空间管理方面引入了多项重要增强：

5.2 NVM Sets 与 Endurance Groups 架构

NVM Sets和Endurance Groups是NVMe 2.0引入的两级资源抽象，实现了比传统单命名空间更精细的资源隔离：

┌────────────────────────────────────────────────────────────┐
│ NVMe Controller │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ Endurance Group 0 │ │ Endurance Group 1 │ │
│ │ (独立PE Cycle预算) │ │ (独立PE Cycle预算) │ │
│ │ ┌──────────────┐ │ │ ┌──────────────┐ │ │
│ │ │ NVM Set 0 │ │ │ │ NVM Set 1 │ │ │
│ │ │ (独立Die组) │ │ │ │ (独立Die组) │ │ │
│ │ │ ┌──┐ ┌──┐ │ │ │ │ ┌──┐ ┌──┐ │ │ │
│ │ │ │NS│ │NS│ │ │ │ │ │NS│ │NS│ │ │ │
│ │ │ └──┘ └──┘ │ │ │ │ └──┘ └──┘ │ │ │
│ │ └──────────────┘ │ │ └──────────────┘ │ │
│ └────────────────────┘ └────────────────────┘ │
└────────────────────────────────────────────────────────────┘

• Endurance Group：耐久度组，拥有独立的PE Cycle预算和寿命监控。适合将不同SLA的租户分到不同EG。
• NVM Set：NVM资源集，拥有独立的Die/Plane资源。同一NVM Set内的NS共享NAND带宽，但与其他Set完全隔离。

厂商白皮书：根据西部数据Ultrastar DC SN650 SSD技术规格书，每个NVM Set包含独立的NAND通道组，跨Set的读写操作互不干扰，可实现接近完全的性能隔离（IO干扰 < 5%）。

5.3 命名空间写保护机制

NVMe 2.0引入了命名空间级别的写保护，通过Identify Namespace中的**NWPC（Namespace Write Protection Capabilities）**字段声明能力，通过Set Features配置：

Namespace Write Protection 状态查询：

// From NVMe 2.0b Section 5.15.2.1 (Identify Namespace Data Structure)
struct nvme_id_ns_write_protect {
__u8 write_protect_state;
#define NVME_NS_WP_NONE 0x0 // No write protection
#define NVME_NS_WP_WRITE_PROTECT 0x1 // Write protected (software)
#define NVME_NS_WP_WRITE_PROTECT_HW 0x2 // Write protected (hardware)
#define NVME_NS_WP_PERMANENT 0x3 // Permanent write protect
};

六、Linux内核nvme-core命名空间管理源码分析

6.1 命名空间探测与创建流程

Linux内核nvme驱动在初始化时，通过以下路径发现和创建设备：

nvme_probe() # PCIe设备探测
└─ nvme_alloc_ctrl()
└─ nvme_init_ctrl()
└─ nvme_scan_ctrl()
├─ nvme_identify_ctrl() # 识别控制器
├─ nvme_init_ns_head() # 初始化命名空间头
└─ nvme_scan_ns_list() # 扫描命名空间列表
├─ nvme_ns_ids_valid()
└─ nvme_create_ns()
├─ nvme_update_ns_info()
│ ├─ nvme_identify_ns()
│ └─ nvme_clear_ns_queue()
├─ nvme_alloc_ns()
│ └─ nvme_alloc_disk()
└─ device_add_disk() # 注册到block层

6.2 关键数据结构

nvme_ns 结构（Linux 6.8内核，简化版）：

// 来自 linux/drivers/nvme/host/nvme.h
struct nvme_ns {
struct list_head list; // 控制器链表节点
struct nvme_ctrl *ctrl; // 所属控制器
struct nvme_ns_head *head; // 命名空间头（多路径共享）
int nshead_id; // NS头ID

struct gendisk *disk; // block层gendisk
struct request_queue *queue; // 请求队列

u32 ns_id; // Namespace ID
u32 lba_shift; // LBA大小移位 = log2(lba_size)
u8 lba_format; // 当前LBA Format索引
u8 pi_type; // Protection Information类型
u8 ms; // 元数据大小
u8 dtype; // 元数据承载方式

sector_t capacity; // 容量（扇区数）
u64 nguid[2]; // Namespace GUID
u8 eui64[8]; // IEEE EUI-64

struct nvme_ns_features features; // 命名空间特性
// …
};

nvme_ns_head 多路径结构：

struct nvme_ns_head {
struct list_head list;
struct device dev;
struct gendisk *disk; // 多路径聚合gendisk
struct nvme_ns *current_ns; // 当前活动路径

struct mutex lock;
struct list_head entry; // 所有路径nvme_ns链表
int node; // NUMA节点
int instance; // 实例编号
u32 ns_id; // 共享的NSID

unsigned inflight; // 在途IO计数
// ANA状态（Asymmetric Namespace Access）
enum nvme_ana_state ana_state;
// …
};

6.3 Format NVM 内核执行路径

用户空间通过BLKRRPRM或nvme-cli的ioctl触发格式化：

// 来自 linux/drivers/nvme/host/core.c
static int nvme_format_ns(struct nvme_ns *ns, u8 lbaf, u8 pi, u8 pil,
u8 ses, bool extended)
{
struct nvme_command c = { };
u32 cdw10 = 0;
int status;

c.format_nvm.opcode = nvme_admin_format_nvm; // 0x80
c.format_nvm.nsid = cpu_to_le32(ns->head->ns_id);
c.format_nvm.cdw10 = cpu_to_le32(cdw10);

/* 设置LBA Format */
cdw10 |= (lbaf & 0xF) << NVME_FMT_LBAF_SHIFT;
/* 设置Protection Information */
cdw10 |= (pi & 0x7) << NVME_FMT_PI_SHIFT;
cdw10 |= pil ? NVME_FMT_PIL_SHIFT : 0;
/* 设置Secure Erase */
cdw10 |= (ses & 0x7) << NVME_FMT_SE_SHIFT;
/* Deallocate Unwritten LBA */
if (ns->features.lba_extended)
cdw10 |= NVME_FMT_DULBE_SHIFT;

c.format_nvm.cdw10 = cpu_to_le32(cdw10);

/* 提交Admin命令，同步等待 */
status = nvme_submit_sync_cmd(ns->ctrl->admin_q, &c, NULL, 0);
if (status) {
dev_err(ns->ctrl->device,
"format namespace %u failed, status %d\\n",
ns->head->ns_id, status);
}
return status;
}

6.4 格式化后的命名空间重配置

格式化完成后，内核需要重新读取命名空间信息，因为LBA大小、容量等可能已变化：

// nvme_update_ns_info – 格式化后刷新命名空间信息
static int nvme_update_ns_info(struct nvme_ns *ns)
{
struct nvme_id_ns *id;
int ret;

/* 重新Identify NS */
ret = nvme_identify_ns(ns->ctrl, ns->head->ns_id, &id);
if (ret)
return ret;

/* 更新LBA大小和容量 */
ns->lba_shift = id->lbaf[NVME_ID_NS_FLBAS_INDEX(id->flbas)].lbads;
ns->lba_format = NVME_ID_NS_FLBAS_INDEX(id->flbas);
ns->capacity = le64_to_cpu(id->nsze);
ns->ms = le16_to_cpu(id->lbaf[NVME_ID_NS_FLBAS_INDEX(id->flbas)].ms);

/* 更新block层参数 */
set_capacity_and_notify(ns->disk, ns->capacity);
blk_queue_logical_block_size(ns->queue, 1 << ns->lba_shift);

/* 如果元数据大小变化，更新DIX配置 */
if (ns->ms && (id->dps & NVME_NS_DPS_PI_MASK))
nvme_config_dix(ns, id);

kfree(id);
return 0;
}

七、nvme-cli命名空间操作实战与格式化性能测试

7.1 常用nvme-cli命名空间操作命令速查

7.2 格式化性能测试

使用三星PM9A3 3.84TB（NVMe 1.4，TLC 3D NAND，PCIe 4.0 x4）进行格式化耗时测试：

测试环境：

• CPU: Intel Xeon Gold 6330 @ 2.0GHz
• 内核: Linux 6.5.0
• nvme-cli: v2.6
• SSD: 三星PM9A3 MZQL23T8HCLS-00A07 (3.84TB)

实测数据：SES=2加密擦除的速度极快（40ms级），因为它只是删除了控制器内部的AES加密密钥，不需要任何NAND操作。这也是企业级SSD实现快速数据销毁的核心机制。

7.3 切换LBA格式前后性能对比

在同一三星PM9A3 3.84TB上，使用fio测试4K随机写（QD=32，iodepth=32，rw=randwrite，bs=4k，runtime=300s，numjobs=1，direct=1）：

结论：对于支持4K原生的SSD和操作系统（Linux 4.x+、Windows 10+、ESXi 6.7+），强烈建议使用4K Native LBA格式，性能提升15%~25%，写放大降低20%以上。

7.4 Format期间的SSD行为监控

使用nvme smart-log在格式化前后监控关键参数变化：

# 格式化前
$ nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning : 0
temperature : 45 C
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 3%
data_units_read : 1,893,234
data_units_written : 2,456,789
media_errors : 0
num_err_log_entries : 2

# 执行SES=1格式化（物理擦除）
$ nvme format /dev/nvme0n1 -s 1
Success formatting namespace:1

# 格式化后（注意data_units_written变化）
$ nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning : 0
temperature : 62 C # 温度升高，擦除操作产热
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 3% # 寿命不变？详见下方说明
data_units_read : 1,893,234
data_units_written : 5,983,210 # 增加约3.5TB（整盘擦除计为写入）
media_errors : 0
num_err_log_entries : 2

重要发现：SES=1格式化会导致data_units_written大幅增加（相当于一次整盘写入），但percentage_used（寿命百分比）可能不变——这取决于厂商是否将Format操作计入TBW。三星、Intel、美光等主流厂商通常不计入，但部分消费级品牌会计入。建议查看厂商Spec文档确认。

八、命名空间安全擦除与数据销毁机制

8.1 三种数据销毁方式对比

8.2 Sanitize vs Format Secure Erase 的区别

NVMe 1.3引入的Sanitize命令与Format的Secure Erase有本质区别：

对比维度 Format SES=1 Sanitize Block Erase
───────────────┬─────────────────────┬──────────────────────
规范定义 │ Format NVM 子功能 │ 独立Admin命令 (0x84)
执行范围 │ 单个Namespace │ 全部NAND介质（含缓存）
覆盖区域 │ 用户数据区 │ 用户区 + OP区 + 缓存
中断恢复 │ 不支持（需重启） │ 支持（从断点继续）
异步执行 │ 否（同步阻塞） │ 是（后台执行）
进度查询 │ Format NVM Log │ Sanitize Status Log
合规认证 │ 部分厂商认证 │ 符合NIST SP 800-88 Rev.1

规范原文：NVMe 2.0b Section 5.26 — “The Sanitize command is used to alter all user data in the controller such that no user data can be recovered from any cache or non-volatile media.”

8.3 不同场景下的数据销毁建议

合规提示：对于GDPR、HIPAA、等保2.0等法规要求的数据销毁，建议使用Sanitize Crypto Erase并获取操作日志，因为它既快速又有明确的合规依据（NIST SP 800-88 Rev.1, Appendix A, Table A-7）。

九、当日知识点小结

十、思考题

参考资料

• NVM Express 2.0b Specification – Section 6.1 Namespace Model & Section 5.15 Identify
• NVM Express 2.0b Specification – Section 5.1 Format NVM Command & Section 5.26 Sanitize
• Samsung PM9A3 NVMe SSD Product Specification (MZQL23T8HCLS)
• Micron 7450 MAX SSD Product Brief – Endurance Groups & NVM Sets
• Western Digital Ultrastar DC SN650 Technical Specification
• Linux 6.8 Kernel – drivers/nvme/host/core.c – Format NVM Implementation
• Linux 6.8 Kernel – drivers/nvme/host/nvme.h – Namespace Data Structures
• NIST SP 800-88 Rev.1 – Guidelines for Media Sanitization
• SNIA 2024 SDC – 4K Native vs 512e Performance Comparison on Enterprise NVMe SSDs
• nvme-cli Official Documentation – Format & Namespace Commands
• JEDEC JESD219 – SSD Endurance Measurement Standard

作者简介：资深RDMA智能网卡、存储技术专家，拥有十余年DPU/RDMA/NVMe SSD芯片测试与工程经验，致力于推动高性能网络技术的开源与普及。