OCP NVME SSD规范解读-3.NVMe管理命令-part2

1. NVMe-AD-8：在某些情况下（如Sanitize命令、Format NVM命令或TCG Revert方法后数据被清除），设备应允许读取已清除的LBAs而不产生错误，并在最后一次清除完成后，对未写入LBAs的读取返回所有零值给主机

2. NVMe-AD-10：设备应支持Identify命令的UUID列表功能（CNS值17h）。

UUID是一个128位的数字，用于唯一标识信息或者对象。在NVMe SSD规范中，使用UUID是为了确保供应商特定的日志标识符和特性标识符能够访问到本规范中定义的功能，而不会意外地访问到其他供应商特定的、可能使用相同标识符的功能。

在规范中，定义了一个特定的UUID值（C194D55BE0944794A21D29998F56BE6Fh），这个UUID被包含在UUID List（NVMe-AD-10）中，并且其Identifier Association字段被设置为清除状态（00b）。

Get Features和Set Features命令需要支持UUID Index功能。当使用这个特定的UUID或者一个零UUID Index，以及规范中使用的供应商特定的Feature Identifier时，这些命令将访问到规范中定义的供应商特定的特性。

Get Log Page命令也需要支持UUID Index功能。当使用这个特定的UUID或者一个零UUID Index，以及规范中使用的供应商特定的Log Page Identifier时，这个命令将访问到规范中定义的供应商特定的日志页。供应商特定的持久事件日志页也需要支持UUID Index功能。

1. NVMe-AD-11：如果特定NVMe管理命令不使用Namespace Identifier（NSID），并且主机指定非零NSID，则控制器应以状态Invalid Field in Command中止命令。

2. NVMe-AD-12：设备应支持Device Self-test命令。

3. NVMe-AD-14/15/16：设备应支持Lockdown命令。Lockdown命令是NVMe管理命令集中的一个命令，主要用于安全和管理目的。当设备接收到Lockdown命令时，它会锁定指定的Admin命令或Features，限制对这些功能的访问或修改。

4. NVMe-AD-17："No-Deallocate Modifies Media After Sanitize"字段的设置是为了确保Sanitize操作后的数据安全性。当这个字段设置为01b时，即使Sanitize操作完成后，设备也不会再对已Sanitize的区域进行写入或修改操作。（nvme协议定义如下）

这样的设计目的是防止在数据被Sanitize清除后，由于设备的内部操作或者意外情况，导致已经清除的数据区域被新的数据覆盖，从而可能影响数据的安全性和清除效果。通过禁止Sanitize操作后对媒体的额外修改，设备可以更好地保证Sanitize命令的执行效果，满足数据安全和隐私保护的需求。例如，在执行Crypto Erase（加密擦除）操作后，设置这个字段为01b可以确保解密密钥不会被再次写入或修改，从而确保被擦除的数据无法被恢复。

1. NVMe-AD-18：这表示设备应在Identify Controller数据结构中的Sanitize Capabilities区域将No-Deallocate Inhibited位清零至0b。这个位主要影响设备在执行sanitize操作后的数据处理方式。

与NVMe-AD-17正好相反，NVMe-AD-18要求设备不应禁止在sanitize操作后进行deallocations，也就是说，设备应该允许在sanitize操作完成后释放已擦除或覆盖的数据块。通过将No-Deallocate Inhibited位设置为0b，设备表明它支持并允许在sanitize操作后进行deallocations。

这一要求的意义在于确保设备在执行sanitize操作后能够有效地管理和回收存储资源，同时保持数据安全性和设备性能。通过遵循这一要求，设备可以更好地满足数据保护和存储管理的需求，特别是在需要频繁进行sanitize操作的高安全环境或特定应用场景中。

1. NVMe-AD-19：
   如果设备在接收到Sanitize命令并成功完成操作后，无法返回全零（即使命令设置了No-Deallocate After Sanitize位为1b），设备应忽略不进行deallocations的请求，并执行deallocations操作。同时，设备应在Sanitize Status Log Page中将Sanitize Status字段设置为100b。

这表示在某些特定情况下，如果设备无法在sanitize操作成功完成后返回零（即无法确保已擦除的数据区域被填充为零），即使Sanitize命令设置了No-Deallocate After Sanitize位为1b（表示请求在sanitize操作后不进行deallocations），设备也应该执行deallocations。

在这种情况下，尽管主机请求不要进行deallocations，但由于设备无法保证返回零，为了数据的安全性和一致性，设备仍然会进行deallocations。同时，设备会在Sanitize Status Log Page中的Sanitize Status字段设置值为100b，以表明sanitize操作的特殊状态或异常情况。

这一要求的意义在于确保设备在执行sanitize操作后能够提供一致和可靠的数据清除效果，即使在某些硬件限制或异常情况下也能保证数据的安全性。通过遵循这一要求，设备可以更好地满足数据保护和安全合规的需求，特别是在需要严格的数据擦除和销毁的环境中。

1. NVMe-AD-22：
   设备出厂时，应在Sanitize Status Log Page中的Sanitize Status字段清除为000b，表示NVM子系统从未进行过sanitize操作，并且Global Data Erased位在Sanitize Status字段中设置为1b，表示全局数据已被擦除。

1. NVMe-AD-24：
   设备应在Identify Controller数据结构中的Asynchronous Event Request Limit字段报告至少为4的值。这表示设备支持至少同时处理4个异步事件请求。

这项要求主要涉及到设备对非易失性内存（NVM）进行格式化的功能。Format NVM命令是一种高级的管理命令，用于在固态硬盘（SSD）上重新初始化或清除特定命名空间的数据。

NVMe-AD-24要求设备支持按命名空间基础执行Format NVM命令，这意味着设备应该能够针对每个独立的命名空间进行格式化操作，而不是同时影响所有命名空间。在Identify Controller数据结构中的Format NVM Attributes字段的位0和位1被设置为00b，这表示设备支持按命名空间进行格式化。

Format NVM命令通常包括几种不同的erase模式，如User Data Erase（仅清除用户数据）、Cryptographic Erase（使用加密技术清除数据）等。特别是在设备退役、转售或更换时，这些erase模式可以帮助提高数据安全性和保护用户隐私。

当主机发送一个Format NVM命令到设备时，设备会根据指定的erase模式和命名空间来执行格式化操作。这个过程可能包括清除namespace中的所有LBA（逻辑块地址）映射、删除用户数据、重置元数据信息以及更新Namespace Utilization（NUSE）等。

Namespace Utilization (NUSE)是NVMe设备中一个重要的概念，用于表示命名空间中当前已分配的逻辑块数量。这些逻辑块已经被分配给数据存储，正在进行读写操作或者已经包含有效数据。

NCAP（Namespace Capacity）是指命名空间的总容量，即可以分配的最大逻辑块数量。而NUSE则是实际已经分配和使用的逻辑块数量，它始终小于或等于NCAP。

NUSE的值是动态变化的。当在命名空间中写入新的数据时，NUSE的值会增加；当删除或覆盖已有数据时，如果设备支持数据压缩或者垃圾回收功能，那么NUSE的值可能不会立即减少，因为被删除或覆盖的数据所在的物理块可能仍然被标记为已使用，直到被设备的后台处理程序进行清理和重用。

通过查询NVMe Identify Namespace数据结构中的相应字段，可以获取到命名空间的NUSE信息。

比如，在一个200GB的设备上，执行Format NVM命令进行用户数据擦除后，NUSE会被设置为零，表示所有逻辑块都没有被分配和使用。然后，每当向设备写入1GB的数据，NUSE的值就会增加相应的逻辑块数量，同时设备的使用数据也会相应地显示已使用的存储容量。

1. NVMe-AD-25：
   如果发生了报告启用的异步事件，并且没有未完成的Asynchronous Event Request命令，控制器应保留这些异步事件类型的事件信息，并在未来对Asynchronous Event Request命令的响应中使用这些信息。排队的重复异步事件应只报告一次。

小编每日撰文不易，如果您看完有所受益，欢迎点击文章底部左下角“关注”并点击“分享”、“在看”，非常感谢！

精彩推荐:

• PCIe surprise down异常与DPC功能分析

• 过度加大SSD内部并发何尝不是一种伤害

• NVMe over CXL技术如何加速Host与SSD数据传输？

• 为什么QLC NAND才是ZNS SSD最大的赢家？

• SSD在AI发展中的关键作用：从高速缓存到数据湖

• 浅析不同NAND架构的差异与影响

• SSD基础架构与NAND IO并发问题探讨

• 字节跳动ZNS SSD应用案例解析

• SSD数据在写入NAND之前为何要随机化？

• 深度剖析：DMA对PCIe数据传输性能的影响

• NAND Vpass对读干扰和IO性能有什么影响？

• HDD与QLC SSD深度对比：功耗与存储密度的终极较量

• NVMe SSD：ZNS与FDP对决，你选谁？

• 如何通过优化Read-Retry机制降低SSD读延迟？

• 关于硬盘质量大数据分析的思考

• 存储系统性能优化中IOMMU的作用是什么？

• 全景解析SSD IO QoS性能优化

• NVMe IO数据传输如何选择PRP or SGL？

• 浅析nvme原子写的应用场景

• 多维度深入剖析QLC SSD硬件延迟的来源

• 浅析PCIe链路LTSSM状态机

• 浅析Relaxed Ordering对PCIe系统稳定性的影响

• 实战篇｜浅析MPS对PCIe系统稳定性的影响

• 浅析PCI配置空间

• 浅析PCIe系统性能

• 存储随笔《NVMe专题》大合集及PDF版正式发布！