错误处理与诊断 - 第433页
我们继续深入中文解析 NVM Express® Base Specification Revision 2.0b，现在从第 8.21 节末尾部分进入第 8.22 节的解读。
📚 第 8.21（续）Sanitize 操作支持、限制与异常处理机制
✅ 控制器对 Sanitize 的支持要求：
若控制器声明支持 Sanitize 命令，则必须：
- 支持至少一种 Sanitize 类型：Block Erase、Overwrite 或 Crypto Erase；
- 所有控制器支持的类型要保持一致；
- 在 Identify Controller 的 Sanitize Capabilities 字段中准确声明支持类型。
🔧 Sanitize Config Feature 的影响（FID = 0x84）
其中的 NODRM（No-Deallocate Response Mode）位 表示：
如果控制器的 Sanitize Capabilities 指出 不支持 No-Deallocate After Sanitize（NDI=1），那当主机发起设置该位为
1的 Sanitize 命令时，该怎么办？
| 模式 | 行为 |
|---|---|
| Error Response Mode | 控制器直接拒绝命令，返回 Invalid Field in Command。 |
| Warning Response Mode | 控制器接受命令，若成功执行，则 Sanitize Status bits[2:0] = 100b，表示“有警告”。 |
🚫 Sanitize 执行期间的限制行为
🔄 情况一：Sanitize 正在进行中
此时，NVM 子系统所有控制器只能执行以下操作：
- 仅允许执行 Admin 命令表（见 Figure 139）中列出的命令；
- 所有 I/O 命令（除
Flush）一律被拒绝，返回状态码：Sanitize In Progress； Flush的行为定义详见 7.1；- 所有未明确允许的命令一律被拒绝；
- 禁止启用 PMR（Persistent Memory Region）：
- 设置
PMRCTL.EN = 1不会使PMRSTS.NRDY变为 0，表示 PMR 不可用。
🚨 情况二：Sanitize 失败，尚未恢复
此状态下，控制器处于 “失败恢复模式”：
- 除
Sanitize命令和 Admin 命令表中列出的命令，全部命令都被拒绝； - 所有 I/O 命令（除
Flush）被拒绝，返回Sanitize Failed； - PMR 依旧不能启用；
- 只有 再次启动 Sanitize 命令 或执行 “退出失败模式”（Exit Failure Mode） 才能恢复。
📦 第 8.22：Submission Queue (SQ) Associations 提交队列关联机制
🎯 定义目的：
当 Predictable Latency Mode（PLM） 启用时（详见 8.16），某些命令可具有 确定性延迟。此时，
SQ Associations提供一种机制：提示控制器哪些 I/O Submission Queues 是用于哪个 NVM Set 的。
这让控制器在调度与资源分配方面更加智能化，有助于：
- 保持 QoS 一致性；
- 提升 PLM 模式下的性能表现。
🧩 特点总结：
| 特性 | 是否强制 |
|---|---|
| SQ Associations 能力是可选 | 否 |
| PLM 功能是否依赖它？ | 否 |
| 是否能提升控制器决策能力？ | 是 |
📝 补充理解建议：
虽然这个功能本身是“提示性质”，但在高负载或多 NVM Set 并行环境下，它对减少 jitter、提升确定性调度是非常关键的优化。
是否需要我补充：
Figure 139中 Sanitize 期间允许的 Admin 命令列表（中英对照）；- 整体 Sanitize 操作状态机图；
- 或是为第 8.21 与 8.22 生成学习用 PPT/PDF 教程？
欢迎告诉我你的偏好，我们可以系统整理 🌟