数据结构与日志格式 - 第243页
深入分析 NVM Express® Base Specification, revision 2.0b - 旋转媒体信息日志页面 (Log Identifier 16h) 和发现日志页面 (Log Identifier 70h)
在这一部分，我们将深入分析两个日志页面：旋转媒体信息日志页面 (Log Identifier 16h) 和 发现日志页面 (Log Identifier 70h)。这两个日志页面在管理旋转媒体和NVM子系统发现过程中的作用至关重要。
Rotational Media Information Log (Log Identifier 16h)
该日志页面用于提供旋转媒体的状态和性能数据，特别是对 Endurance Groups（耐久组）中存储数据的旋转媒体。该信息在系统重启或电源断开后会持续存在。
关键字段分析：
- Load Count
-
记录成功的执行器加载事件的总数。每当执行器从非操作状态过渡到操作状态时，该计数就会增加。
-
Failed Load Count
-
记录失败的执行器加载事件的总数。每当执行器从非操作状态过渡到操作状态失败时，该计数就会增加。
-
Spinup Count
-
表示成功的启动次数。每当控制器的电源状态从非操作状态转为操作状态时，成功的启动事件计数会增加。
-
Failed Spinup Count
- 记录失败的启动次数。当控制器尝试从非操作状态转为操作状态失败时，失败的启动事件计数会增加。
通过这些字段，主机可以获取旋转媒体的运行状态，了解执行器的健康状况，以及每个旋转媒体的启动和加载事件。这些数据对于监控存储设备的寿命和健康至关重要。
Discovery Log Page (Log Identifier 70h)
发现日志页面 是专门为 Discovery 控制器 设计的，旨在为主机提供 NVM 子系统 的目录信息。通过此日志，主机可以尝试与一个或多个 NVM 子系统进行关联。此日志页面在电源循环过程中保持不变。
关键字段分析：
- SUBTYPE
-
用于指示该记录是引用另一个发现服务（
SUBTYPE 01h）还是指向一个包含控制器的 NVM 子系统（SUBTYPE 02h）。这有助于主机了解不同的子系统和服务类型。 -
Controller ID
-
如果 NVM 子系统支持动态控制器模型，则该字段的值为
FFFFh。对于支持静态控制器模型的子系统，则Controller ID为FFFEh。 -
Generation Counter
-
该字段用于标识日志页的版本。如果在读取过程中发现日志页的内容发生变化，主机会收到
Discover Restart状态代码。主机需要通过重新读取整个日志并比对 Generation Counter 来确保一致性。 -
Log Page Offset
- 主机可以使用此字段来检索特定记录。当日志过长时，主机可使用多个 Get Log Page 命令进行分页读取。通过设置正确的偏移量，可以逐步读取完整的发现日志页面。
日志页面处理机制：
-
动态控制器模型： 在此模式下，每个 NVM 子系统的记录将包括
Controller ID = FFFFh，这表示该控制器是动态的，无法明确指示唯一控制器。 -
静态控制器模型： 在此模式下，每个 NVM 子系统的记录包括
Controller ID = FFFEh，这表示该控制器的标识符是静态且固定的。 -
Referral Mechanism： 如果记录的子类型是 SUBTYPE 01h，则表示这是一个指向其他发现服务的引用机制（最多支持八级引用）。
总结：
-
旋转媒体信息日志页面 (Log Identifier 16h)：为主机提供关于存储在旋转媒体上的数据的详细信息，特别是对执行器和旋转启动/加载事件的监控。这些信息对于确保旋转媒体的健康状态和可靠性至关重要。
-
发现日志页面 (Log Identifier 70h)：为主机提供有关可与之关联的 NVM 子系统的信息，特别适用于动态和静态控制器模型。主机通过此日志了解系统中的其他子系统、服务及其状态，进而进行进一步的操作。
这些日志页面不仅为主机提供了系统资源的详细视图，还确保了系统配置和状态的一致性，帮助管理员有效地管理存储系统。