错误处理与诊断 - 第435页
我们继续深入分析 NVMe Base Specification Revision 2.0b 第 8.24 节末尾部分，聚焦于：
🔍 Telemetry 数据日志结构与采集流程深入讲解
✅ Telemetry 数据日志类型（Telemetry Data Logs）
NVMe 标准定义了两种遥测数据日志页：
- Host-Initiated Log Page（主机发起）
- Controller-Initiated Log Page（控制器主动触发）
📏 结构组成
无论哪种日志类型，其结构都由多个固定大小的 Telemetry Data Block（512 字节）组成，这些 Block 又被划分为多个 Telemetry Data Area：
| Data Area 编号 | 说明 | 大小 | 用途阶段 |
|---|---|---|---|
| Area 1 | Small（小型） | ⬇︎ | 问题初识阶段 |
| Area 2 | Medium（中型） | ⬆︎ | 问题调查阶段 |
| Area 3 | Large（大型） | ⬆︎⬆︎ | 根因分析阶段 |
| Area 4（可选） | Extra-Large（特大型） | ⬆︎⬆︎⬆︎ | 深度诊断阶段 |
⚠️ Data Area 4 只有在：
- Log Page Attributes.bit[6]=1；
- ETDAS=1h（即主机行为支持扩展遥测区）
的情况下才被支持。
🔄 主机采集控制器遥测数据的标准流程（Operational Model）
以下是 Host 收集 Telemetry 数据的推荐步骤：
📘 第一步：确认支持
- 主机通过读取
Identify Controller数据结构确认是否支持 Telemetry Log Page； - 通过设置
Host Behavior Support Feature → ETDAS = 1h，声明支持 Area 4（若支持）；
📦 第二步：准备空间
- 如果主机需要保存遥测数据，应提前分配存储区；
🔔 第三步：配置事件通知
- 主机启用
Asynchronous Event Configuration中的 Telemetry Log Notices，以便在控制器准备好 Telemetry 数据时能收到通知；
📥 第四步：数据采集
主机开始收集 Telemetry 数据（无论是 Host-Initiated 还是 Controller-Initiated）：
- 步骤 a：读取对应的 Telemetry Log Page
- 推荐读取全部可用的 Area 1～4；
- 每次读取单位是 512 字节的 Telemetry Data Block；
-
使用
Retain Asynchronous Event = 1表示“保持未读标志”； -
步骤 b：校验一致性
- 重读日志头并确认
Data Generation Number是否与第一次读取一致； -
若不一致，表明日志可能更新，应重新读取；
-
步骤 c：确认读取完成（仅适用于控制器发起的日志）
-
主机应再次读取日志页，并设置
Retain Asynchronous Event = 0，通知控制器数据已读取完成； -
步骤 d：转发数据
- 将日志数据转发给控制器厂商，用于问题分析与产品改进；
⏱️ 主机发起采集的触发场景
主机可以在以下场景发起 Telemetry 数据采集：
- 系统崩溃后的紧急调试；
- 正常运行过程中，主动调试和记录问题；
通过 Get Log Page 命令并设置：
Log Specific field → Create Telemetry Host-Initiated Data = 1
控制器应尽可能快速（推荐 <1 秒）返回结果，以避免系统重启前无法完成数据保存。
✅ 小结与建议
| 项目 | 内容 |
|---|---|
| ✅ 支持方式 | 主机通过 Identify Controller 与 Host Behavior Support 配置 |
| ✅ 结构 | Telemetry 分为最多四个 Area，每个由若干 512B Block 组成 |
| ✅ 操作流程 | 获取 → 校验 → 确认读取完成（控制器发起时） → 上报厂商 |
| ✅ 应用场景 | 崩溃分析、稳定性测试、性能瓶颈调查等 |
| ⚠️ 注意事项 | 若数据不一致，需重读；注意异步事件的读取确认机制 |
如果你需要我进一步：
- 绘制 Telemetry 四阶段采集机制流程图；
- 制作 Log 读取与一致性校验的操作示意图；
- 或为遥测流程生成 调试脚本示例（如 Linux NVMe CLI 操作）；
告诉我即可，我马上为你整理出来！🛠️📊