存储基础知识：SSD 固态硬盘、M.2 接口与 NVMe 协议介绍 ​

本文档面向 openUBMC 社区的新开发者，对 BMC 存储管理中最常接触到的三个基础概念——SSD-Format（SSD 固态硬盘基础知识）、M.2 接口、NVMe 接口——进行系统性介绍，并结合 storage 组件的业务代码说明这三类知识在 openUBMC 中的实际落地形式，便于读者快速建立"存储介质 → 物理接口 → 通信协议 → BMC 软件实现"的整体认知。

阅读本文档前，建议先了解 硬盘背板开发指南 与 硬盘管理手册，能够更好地把概念和实际开发流程对应起来。

概述：本文档的三个知识点 ​

围绕一块固态硬盘（Solid State Drive，SSD）从硬件介质到 BMC 管理的完整链路，本文档自底向上介绍三个互相关联的知识点：

1. SSD-Format（SSD 固态硬盘基础知识）——介绍 SSD 是什么、内部如何工作（前端 / FTL / 后端三大模块）、以 NAND Flash 为代表的存储介质类型（SLC/MLC/TLC/QLC）、容量 / 性能 / 寿命 / 可靠性 / 功耗等核心参数，以及 SSD 的标准外观尺寸（Form Factor）。这是理解后续所有 SSD 相关内容的基础。
2. M.2 接口——SSD 当前最常见的物理接口/形态规范之一，定义了模组尺寸、Key 缺口与可承载的总线协议。M.2 是 SSD 走向"小型化、高速化"的代表性物理形态。
3. NVMe 接口——面向 PCIe SSD 重新设计的高性能逻辑设备接口协议，配套 NVMe-MI 子规范专门用于 BMC 带外管理。NVMe 是 SSD 高性能潜力得以释放的关键软件层。

1. SSD-Format：SSD 固态硬盘基础知识 ​

1.1 什么是 SSD ​

固态硬盘（Solid State Drive，SSD） 是一种以半导体存储介质（主流为 NAND Flash，少数采用 3D XPoint、MRAM 等新型介质）为核心的非易失性存储设备。它没有机械硬盘（HDD）那样的盘片、磁头、马达等机械部件，所有的读、写、擦除操作都由电信号在芯片内部完成。

相比 HDD，SSD 的核心优势：

NAND Flash 的物理特性也带来了 SSD 必须解决的几个独特问题：

• 闪存不能覆盖写：写入新数据前必须先擦除（Erase）整块；
• 读写擦的最小粒度不同：读 / 写按"页（Page，4~16 KB）"为单位，擦除按"块（Block，由若干 Page 组成）"为单位；
• 闪存有寿命：每个块的编程/擦除（P/E）次数有上限。

正是这些特性，催生了 SSD 内部独有的 FTL、垃圾回收、磨损平衡等机制，下文将依次介绍。

1.2 SSD 内部架构与基本工作原理 ​

一块 SSD 在结构上可以分成三个功能模块：前端（Front End）、FTL（Flash Translation Layer）、后端（Back End）。它们配合完成主机命令到闪存物理操作的转换：

• 前端：通过 SATA / SAS / PCIe 等物理接口，实现 ATA / SCSI / NVMe 等协议；负责命令解析、CRC 校验、DMA 控制。
• FTL：SSD 的"灵魂"，维护一张"逻辑块地址 → 物理闪存位置"的映射表。例如 128 GB SSD、4 KB 逻辑块、4 字节物理地址，则映射表大小为 32M × 4B = 128 MB（一般缓存在 DRAM 中）。FTL 还负责垃圾回收、磨损平衡、坏块管理等关键算法。
• 后端：按 ONFI 或 Toggle 协议与 NAND Flash 通信，包含 ECC 编解码、多通道并发控制（每个通道一个独立控制器）、命令队列管理。
• DRAM 缓存（部分盘有）：缓存映射表与用户数据，加速访问；为防止突然掉电丢数据，企业级 SSD 通常内置备用电容用于"刷脏数据"。

SSD 写操作流程： 主机通过接口下发写命令→数据先缓存在 SSD 内部 RAM→FTL 为每个逻辑块分配一个闪存物理地址→数据凑够一定数量后由后端真正写入闪存→更新 FTL 映射表。 SSD 读操作流程： 主机下发读命令→FTL 查映射表得到物理地址→后端读出数据→前端返回主机。

1.3 NAND Flash 介质类型 ​

按"每个存储单元（Cell）能存几个 bit"，NAND Flash 主要分为：

为了在硅片单位面积放下更多 bit、降低每 GB 成本，闪存还从平面（2D）走向了立体（3D）堆叠工艺，目前已发展到数百层堆叠。3D NAND 让 SSD 在容量、寿命与成本之间取得了新的平衡。

1.4 SSD Form Factor（外观尺寸） ​

SSD 是标准件，外观尺寸需要满足规定要求（长 × 宽 × 高 + 接口连接器），这通常称为 Form Factor。常见的 SSD Form Factor：

第 2 章会详细介绍其中最常见的 M.2 形态。

1.5 SSD 核心参数 ​

SSD 产品规格书中通常包含以下核心参数（以 Intel DC S3710 等数据中心盘为典型样本）：

1.5.1 容量与 Over Provisioning ​

• 裸容量 vs 用户容量：闪存物理容量按二进制（GiB）计算，称为"裸容量"；提供给用户的容量按十进制（GB）计算，称为"用户容量"。前者比后者多约 7%（GB 级），TB 级时差异更大。
• Over Provisioning（OP）：多出来的容量并不是浪费，而是被 SSD 用作 FTL 映射表存储、垃圾回收交换空间、坏块替代空间。OP 越大，垃圾回收效率越高、写放大越低、寿命越长。
• 计算公式：$OP = (物理容量 - 用户容量) / 用户容量$

1.5.2 性能指标 ​

测试性能时还要考虑访问模式：Random/Sequential（地址是否连续）、Block Size（4KB ~ 512KB）、Read/Write Ratio（读写比例）。

1.5.3 寿命指标 ​

TBW 与 DWPD 的换算公式：

其中 WAF（Write Amplification Factor，写放大系数） 与 SSD 固件设计、用户写入模式（顺序 vs 随机）强相关，是衡量 SSD 寿命友好度的关键值（理想 = 1，越大越伤盘）。

应用按读写比例可分为 Write Intensive（写密集，DWPD 通常 > 3）与 Read Intensive（读密集，DWPD 通常 < 1），不同类型应用应选择匹配 DWPD 等级的 SSD。

1.5.4 数据可靠性指标 ​

闪存出厂时即有一个 RBER 指标，企业级与消费级显著不同。RBER 还会随 PE Cycle 增长而升高、随读取干扰（Read Disturb）累积而升高，需要 ECC（如 BCH、LDPC）+ RAID5 等机制持续保护。

1.5.5 功耗模式 ​

SSD 定义了多种功耗状态，从大到小依次为：

主机系统功耗状态（S0~S5）与 SSD 设备状态一一对应：S0 工作 → S3 睡眠 → S4 休眠 → S5 软关机，SSD 被动响应主机的功耗切换。

发热控制方面，当温度传感器侦测到达到阈值（如 70°C）时，固件会启动热节流（Thermal Throttling），限制闪存后端并发写的个数，以性能换温度。

1.6 SSD 关键内部机制 ​

1.6.1 FTL（Flash Translation Layer） ​

FTL 的核心职责是维护"逻辑地址（LBA）→ 物理闪存位置（PBA）"的映射，并屏蔽闪存"不能覆盖写、按块擦除"等物理特性，让上层 OS 看到一个普通的块设备。FTL 算法决定了 SSD 的性能、可靠性和功耗——同样的闪存芯片，不同的 FTL 实现可能跑出几倍的性能差距。

1.6.2 垃圾回收（Garbage Collection，GC） ​

由于闪存不能覆盖写，主机的"覆盖写"操作在 SSD 内部实际上是"写到新位置 + 把旧位置标记为无效"。随着时间推移，闪存中会积累大量无效数据（垃圾），FTL 必须定期把仍然有效的数据从一个或多个块搬移并集中写到空闲块上，然后整体擦除原块以释放空间。这就是垃圾回收。

1.6.3 磨损平衡（Wear Leveling） ​

每个闪存块的 P/E 次数有上限。如果热点数据始终写在固定块上，这些块会很快报废，而其他块还很新——整盘寿命就会被短板拖累。FTL 必须尽量让所有块的 P/E 次数均衡，这就是磨损平衡。一般通过"动态磨损平衡"+"静态磨损平衡"两套策略协同。

1.6.4 写放大（Write Amplification, WAF） ​

由于 GC、磨损平衡、数据搬移、ECC 等机制，SSD 实际写入闪存的数据量往往大于主机写入的数据量。

WAF 越接近 1 越好。顺序写 + 大块写 + 大 OP，可显著降低 WAF。

1.6.5 系统兼容性 ​

性能、寿命、可靠性都很优秀但"上机变砖"——这是 SSD 工程实践中最让人头疼的问题。系统兼容性主要包括：

• BIOS / OS 兼容性：SSD 上电后，BIOS 进行链路协商、Identify、SMART 读取、加载 MBR；任何一步失败都会导致系统启动失败；
• 电信号/硬件兼容性：在主机信号抖动、信号完整性差但仍在规范误差范围内的情况下，SSD 仍能正常工作；
• 容错处理：异常掉电、命令超时、链路重置等情况下的健壮性。

1.7 openUBMC 中对 SSD 的管理 ​

storage 组件并不直接执行 SSD 的读写或 FTL 算法（这些都在 SSD 控制器内部），但需要在 BMC 带外把 SSD 的"健康度、寿命、温度、容量、型号"等信息感知出来并上报到资源树。下面把第 1 章涉及到的 SSD 基础概念，与 openUBMC 中的实际属性、接口对应起来：

1.7.1 SSD 类型与基础信息 ​

1.7.2 SSD 寿命与健康度 ​

bmc.kepler.Systems.Storage.Drive.DriveSubHealth 与 bmc.kepler.Systems.Storage.Drive.NVMe.SMART 接口集中体现了第 1.5、1.6 节中的关键概念：

1.7.3 SSD 信息的获取通道：SSD Form Factor (SFF) VPD 协议 ​

要让 BMC 把上述信息从 SSD 中取出来，需要一个带外可达的获取通道。openUBMC 实现了两种 NVMe SSD 信息获取协议（详见第 3.7、3.8 节的 NVMe-MI 介绍）：

• NVMe-MI VPD：基于 NVMe 控制器，通过 MCTP 报文获取，能力丰富；
• SSD Form Factor (SFF) VPD：由 SNIA SFF 工作组定义的 VPD（Vital Product Data）描述协议，规定了 PCIe SSD 的 VendorId、SerialNumber、ModelNumber、LinkSpeed、LinkWidth 等基础字段在 VPD chip（独立 EEPROM）中的固定偏移布局，BMC 只需通过 SMBus 直接读取 VPD chip 即可获得这些信息，无需依赖 NVMe-MI 协议栈。SFF 协议位于 storage/src/lualib/nvme/sff_protocol/ssd_form_factor.lua，是 openUBMC 适配老型号、不支持 NVMe-MI 的 SSD 时的兜底方案。

storage/src/lualib/common_def.lua 中定义了三种 VPD 协议枚举：

NVME_VPD_PROTOCOL_NVME_MI = 0,
NVME_VPD_PROTOCOL_SSD_FORM_FACTOR = 1,
SAMSUNG_NVME_VPD_PROTOCOL_SSD_FORM_FACTOR = 2,

第三种 SAMSUNG_NVME_VPD_PROTOCOL_SSD_FORM_FACTOR 用于兼容三星部分老型号 SSD（如 SAMSUNG MZQLB960HAJR、MZQLB1T9HAJR 等系列）在标准 SFF 之上的差异化布局。

SFF VPD 关键字段偏移（common_def.lua 第 1028~1039 行）：

协议自动识别流程（storage/src/lualib/nvme/vpd_connector.lua 中 verify_vpd_protocol）：

判定结果会写入 Connector_ComVPD 对象的 AuxId 属性，框架据此通过 Bom + Id + AuxId 组合加载具体的协议 SR 文件（如 14140224_PROTOCOL_0.sr），完成 NVMe 对象（c_nvme）的实例化。详细 SR 加载链路参见 storage/README.md 的"配置 NVME 盘"章节。

2. M.2 接口 ​

2.1 接口定义与历史 ​

M.2（pronounced "em-dot-two"），原名 NGFF（Next Generation Form Factor），是一种为内置式计算机扩展卡和连接器制定的规范。它由 SATA-IO 在 SATA 3.2 规范中正式标准化（2013 年 8 月发布的 gold revision），由 PCI-SIG 在 2013 年 12 月发布的 M.2 specification revision 1.0 中提供详细电气与机械规范，目标是替代体积更大、性能受限的 mSATA（Mini SATA）与 mini PCIe 接口。

服务器领域，M.2 通常以"启动盘""日志盘"或"L2 缓存盘"的形态存在，BMC 需要在带外感知它的在位状态、容量、健康度、温度、剩余寿命等信息。

M.2 的关键设计意图：

• 更小的占板面积——M.2 SSD 仅占主板面积的 5%~10%，约为 2.5 英寸盘的 1/5；
• 支持更高速率——直接暴露 PCIe ×4，原生兼容 NVMe；
• 多协议复用——同一个连接器同时可承载 PCIe、SATA、USB、I²C、SMBus、UART、SDIO 等总线，通过 Key 缺口区分；
• 多功能模组——除 SSD 外还可承载 Wi-Fi、Bluetooth、WWAN、GPS、NFC 等设备。

2.2 物理结构与尺寸规格 ​

M.2 模组形状为长方形 PCB，一端为金手指（edge connector，75 个位置最多 67 个引脚，0.5 mm pitch，正反两面引脚错位），另一端中心为半圆形固定螺孔，安装时通过单颗螺丝固定在主板上。

电气与机械规格：

模组命名规则为 WWLL-HH-K-K，其中：

• WW 表示宽度（mm）；
• LL 表示长度（mm）；
• HH 编码模组单/双面以及最大元件厚度（如 D2、D3、D5）；
• K-K 表示 Key 缺口位置（如 B-M、M）。

实际可用的尺寸规格：

主板上的 M.2 socket 通常会预留多个螺孔位置，以兼容多种长度的模组。

2.3 Key 缺口与协议复用 ​

M.2 通过模组金手指上不同位置的 Key 缺口来区分总线协议，主板 socket 也对应不同的"键位"，二者必须匹配才能插入。完整的 Key 列表如下：

服务器存储场景中需要重点关注的两类：

• B Key（Socket 2）：支持 SATA、PCIe ×2、USB、I²C/SMBus，多用于无线网卡及部分低速 SSD；
• M Key（Socket 3）：支持 SATA、PCIe ×4 与 SMBus，是高性能 NVMe SSD 的标准 Key 类型。

带 B+M 双缺口的模组只用 PCIe ×2，但能同时插入 Socket 2 和 Socket 3，兼容性更强；只带 M 单缺口的模组占满 PCIe ×4，性能更高但只能插 Socket 3。

2.4 速率与协议能力 ​

M.2 接口本身不限定具体协议，实际速率由所走协议决定：

NVMe 协议正是基于 PCIe 链路对队列、命令、中断进行了重新设计，把延迟从 SATA 的 ~100 μs 量级降低到 ~10 μs 量级，是 M.2 高性能形态的灵魂——这也是后续第 3 章要详细介绍的内容。

2.5 设计要点 ​

在硬件层把一颗 M.2 SSD"用好"，需要关注以下几个工程实践：

信号完整性（Signal Integrity）

• PCIe 差分对阻抗控制：单端 50Ω、差分 100Ω，PCIe 4.0/5.0 长度匹配误差通常要求 ≤ 5 mil；
• 高速过孔背钻（Backdrill）：消除残桩（Stub），PCIe Gen5 建议残桩 < 5 mil；
• 完整参考地平面：避免高速差分对跨分割（split plane）。

电源完整性（Power Integrity）

• 主供电 3.3V，PCIe NVMe SSD 峰值电流 ≥ 2A；
• 去耦电容：每颗 SSD ≥ 10μF（低频）+ 0.1μF（高频）+ 0.01μF（超高频陶瓷）；
• 电源纹波控制 < 50 mVpp；高功耗模组建议为 NVMe 控制器单独分配电源层。

散热设计

• 高性能 NVMe SSD 功耗可达 8~10 W，需配置散热片或导热垫；
• 集成 SMART 温度传感器，触发热节流（Thermal Throttling）保护；
• 服务器场景通常配合机箱风道设计，避免热堆积导致 SSD 主控降频。

热阻公式： $T_{junction} = T_{ambient} + (P_{loss} \times R_{\theta JA})$

其中 $R_{\theta JA}$ 为芯片到环境的热阻系数，工业级 NVMe SSD 通常要求 < 10°C/W。

2.6 openUBMC 中对 M.2 盘的处理 ​

在 openUBMC 中，M.2 盘并不是一个独立的"对象类型"，而是 NVMe / SATA 直通盘的一种具体物理形态。storage 组件主要在以下两个层面体现 M.2 相关能力：

• MediaType 上报：在 bmc.kepler.Systems.Storage.Drive 接口中，MediaType 字段标识硬盘介质类型（HDD/SSD/SSM），M.2 NVMe SSD 上报为 SSD。
  33:34:storage/src/lualib/nvme/sff_protocol/ssd_form_factor.lua

  local PROTOCOL_PCIE <const> = 6
  local MEDIA_SSD <const> = 1

• MediumFormFactor 映射：Redfish 接口中 MediumFormFactor 字段使用 SCSI/SBC 规范定义的枚举，M.2 形态对应数值 7（参见 storage/docs/25.12/openUBMC 支持redfish接口补齐Storages和Drive相关资源.md）。

在硬件适配层面，M.2 盘走的是与普通 NVMe 直通盘一致的"硬盘背板 + Connector + VPD"链路（见 storage/README.md "配置 NVME 盘"小节），整体加载流程如下：

storage/CHANGELOG 中也能看到针对 M.2 盘的多次专项修复，例如：

[1.90.24] - 2026-02-09  恢复出厂场景从本地持久化恢复盘信息，避免 M.2 盘信息丢失
[1.80.175] - 2025-12-19  BIOS 上报的 M.2 盘信息，去掉后置空格

2.7 演进与替代方案 ​

围绕 M.2 也出现了若干衍生/替代标准，简单了解即可：

• NGSFF / NF1 / M.3：Samsung 2017 年推出，用于服务器；宽度从 22 mm 增加到 30.5 mm，使用 12V 供电、支持热插拔、单接口可走两个 PCIe 端口。
• EDSFF（E1.S / E3.S 等）：企业及数据中心标准长条形热插拔模组，正在逐步替代 U.2/U.3 在数据中心的位置。
• XFM / XFM Express（JEDEC JESD233）：尺寸更小的新型存储模组，使用 NVMe over PCIe，目标替代部分 M.2 与板载存储。

3. NVMe 接口 ​

3.1 NVMe 协议概述 ​

NVMe（NVM Express，Non-Volatile Memory Express） 是 NVM Express, Inc. 维护的一种基于 PCIe 总线的高性能存储逻辑设备接口规范，专为 SSD 这类低延迟、高并行度的非易失性介质设计。它从命令队列模型、中断处理、寄存器访问到固件管理都进行了端到端的优化，是当前 NVMe SSD 的事实标准协议。

NVMe 的核心特性：

• 低延迟：PCIe 直连 CPU，无 HBA 中间层；执行命令时无需读取寄存器；典型延迟 < 100 μs。
• 高并行：支持最多 65535 个 I/O 队列，每队列最多 65536 命令；理论 IOPS = 队列深度 / IO 延迟，多队列大幅提升随机 IOPS。
• 可扩展：支持 NVMe over Fabrics（NVMe-oF），可通过 RoCE / TCP / FC / InfiniBand 把 NVMe 协议扩展到网络层面，实现远程存储访问。
• 低功耗：内置自动功耗状态切换（PS0~PS4）、动态能耗管理、免驱（OS 内核内置驱动）等机制。

NVMe 协议中的关键术语：

3.2 NVMe vs AHCI 详细对比 ​

NVMe 之所以能取代 AHCI 成为 PCIe SSD 的事实标准，关键在于二者的设计哲学差异：AHCI 是为机械硬盘设计的，存在 HBA、寄存器访问、单队列等历史包袱；NVMe 则是为 SSD 从零设计。

3.3 NVMe 命令体系 ​

NVMe 把所有命令分为两大类，分别在不同的 Queue Pair 中执行：

3.3.1 Admin Command（管理命令） ​

只能提交到 Admin Queue Pair（Admin SQ / CQ），用于控制器管理与少量 NVM 控制操作。常见 Opcode：

3.3.2 IO Command（NVM Command） ​

只能提交到 I/O Queue Pair，主要负责数据传输：

3.3.3 命令执行流程 ​

NVMe 通过 SQ、CQ、DB 三种结构配合完成一次命令的下发与回收：

NVMe 推荐使用 MSI-X 中断（最多 2048 个中断向量），允许每个 CQ 单独发送自己的中断，相比 AHCI 的"一个中断提醒所有队列"显著提升并发性能。

3.4 多命令队列与仲裁机制 ​

NVMe 协议允许 host 在多个 SQ 中同时提交命令，由控制器选择从哪个 SQ 中取命令执行——这就是**仲裁（Arbitration）**机制。NVMe 协议定义了三种仲裁方式：

• Round Robin（RR）：Admin SQ 与所有 I/O SQ 优先级相同，每次轮转选择一个队列；
• 带权重的 RR（Weighted Round Robin with Urgent Priority Class）：定义 3 个严格优先级 Priority1 > Priority2 > Priority3，高优先级有命令则优先执行（非抢占式）：
  • Priority1：Admin
  • Priority2：Urgent
  • Priority3：I/O SQ（再细分 4 级权重 U/H/M/L）；
• 厂商自定义（Vendor Specific）：厂商可在协议范围内自定义仲裁策略。

每个 SQ 由 16 bit 的 QID 唯一标识，由 host 在创建队列时分配。

3.5 NVMe 物理形态（Form Factor） ​

NVMe 是一种逻辑协议，可以承载在多种物理形态之上。常见形态：

M.2 与 NVMe 的关系澄清：M.2 是物理形态/接口，NVMe 是逻辑协议。一块 M.2 SSD 可以是 SATA 协议（走 AHCI），也可以是 PCIe 协议（走 NVMe 或 AHCI）。市面上"M.2 NVMe SSD"特指"M.2 物理形态 + PCIe 通道 + NVMe 协议"的组合。

3.6 NVMe 协议版本演进 ​

NVMe 标准从 2011 年发布 1.0 版本至今持续演进，每个版本的关键能力如下：

3.7 NVMe-MI：BMC 带外管理 NVMe 盘的钥匙 ​

NVMe-MI（Management Interface） 是 NVMe 体系中专门为带外管理设计的子规范。BMC 通过 SMBus 或 MCTP-over-PCIe / MCTP-over-SMBus 与 NVMe 控制器交互，可以在主机下电、OS 不可达的情况下获取 SMART、固件版本、温度、寿命、Identify、Telemetry Log 等信息，无需经过主机驱动栈。

NVMe-MI 报文有以下三类：

• NVMe-MI Command（NVMe Management Interface Specific）：管理子系统级别的命令，例如读取子系统信息、Configuration Get/Set、VPD Read/Write 等；
• NVMe Admin Command（封装在 NVMe-MI 报文中）：转发上述 3.3.1 节中的 Admin 命令，常用 GetLogPage（SMART、FW Log、Persistent Event Log）、Identify 等；
• PCIe Command：少量 PCIe 配置访问能力。

3.8 openUBMC 中的 NVMe-MI 实现 ​

openUBMC 的 NVMe-MI 协议栈位于 storage/src/lualib/nvme/nvme_mi_protocol/，分层结构如下：

storage/src/lualib/nvme/nvme_mi_protocol/
├── nvme_mi.lua                        # NVMe-MI 高阶接口（GetLog/SMART/FW Log 等）
├── nvme_mi_def.lua                    # 协议常量、Opcode、bitstring 报文模板
├── nvme_mi_command.lua                # NVMe-MI 命令封装
├── nvme_mi_admin_command.lua          # NVMe Admin 命令封装（GetLogPage、Identify…）
├── nvme_admin_command_process.lua     # Admin 命令处理流水线
├── nvme_mi_mctp.lua                   # 与 mctpd 的对接，发送/接收报文
└── nvme_mi_dump_log.lua               # 异常一键收集（Telemetry Log）

NVMe-MI 报文最终通过 mctpd 提供的 Endpoint 对象发送到 NVMe 控制器：

storage 组件最终把 NVMe 盘的信息上树到以下接口（详见 storage/README.md）：

对应的 IPMI 命令分布在 IpmiCmds/38/13（如 GetNvmeInfo、GetNvmeNum），用于带外查询 NVMe 盘的数量及基本信息。

4. 三者在 openUBMC 中的整体协作 ​

下图概括了 SSD-Format（SFF VPD）、M.2、NVMe（含 NVMe-MI）在 openUBMC 存储管理体系中的位置：

关键流程小结：

1. 硬件层：M.2/U.2/EDSFF 是常见的 NVMe 物理形态，硬件背板通过 SMBus 暴露 VPD chip，通过 PCIe / MCTP 暴露 NVMe 控制器；
2. 协议探测（与第 1.7.3 节关联）：vpd_connector.lua 读取 VPD chip 前 8 字节的公共头，按 SFF / NVMe-MI VPD / Samsung 变体进行判定；
3. 数据采集：基础 VPD（厂商、型号、SN、链路速率，参见第 1.7.1 节）由 sff_protocol/ssd_form_factor.lua 一次性读取；运行时 SMART / 寿命 / 温度等动态信息（参见第 1.7.2 节）由 nvme_mi_protocol/nvme_mi.lua 周期性获取；
4. 对象上树：nvme_object.lua 中的 c_nvme 对象将基础与动态信息整合后，通过 slot 关联到 c_drive，最终上树到 bmc.kepler.Systems.Storage.Drive 及其子接口，对外提供 Redfish/IPMI/RPC 查询能力；
5. 健康度告警：基于第 1.5、1.6 节中的 SSD 寿命、可靠性、热节流等机制，storage 组件还会监听 Drive.NVMe.SMART.CriticalWarning、PredictedMediaLifeLeftPercent、TemperatureCelsius 等属性，触发对应的告警事件上报。

5. 总结 ​

• SSD-Format（SSD 固态硬盘基础知识）

  • SSD 由前端、FTL、后端三大模块构成，FTL 是其灵魂——通过逻辑→物理映射、垃圾回收、磨损平衡、写放大控制等机制屏蔽 NAND Flash"不能覆盖写、按块擦除、有 P/E 寿命"的物理特性；
  • NAND Flash 按存储密度分为 SLC / MLC / TLC / QLC，性能、寿命、价格依次下降，目前消费级以 3D TLC 为主；
  • 衡量 SSD 的核心参数包括：容量与 OP、性能（IOPS / 吞吐 / 时延 / QoS）、寿命（DWPD / TBW / PE Cycles / WAF）、可靠性（UBER / RBER / MTBF）、功耗（Idle / Max Active / Standby / DevSleep）、外观尺寸（Form Factor）；
  • 在 openUBMC 中，SSD 的基础信息通过 bmc.kepler.Systems.Storage.Drive 接口对外呈现，健康度信息通过 Drive.DriveSubHealth 与 Drive.NVMe.SMART 接口呈现，信息获取通道支持 NVMe-MI 与 SSD Form Factor (SFF) VPD 两种协议，由 vpd_connector.lua 自动探测选择。

• M.2 接口

  • 一种物理接口/形态规范，定义了模组的外形尺寸（2230/2242/2260/2280/22110 等）、Key 缺口（B/M/B+M 等）与可承载的总线协议（SATA、PCIe、USB、I²C/SMBus 等）；
  • 在 openUBMC 中以 NVMe / SATA 直通盘的形式被管理，Redfish 中通过 MediumFormFactor=7 标识，与普通 NVMe 直通盘共享同一套自发现 / 上树流程。

• NVMe 接口

  • 一种基于 PCIe 的高性能存储逻辑协议，通过多队列、无锁并发、MSI-X 中断、SGL/PRP 寻址等机制大幅超越 AHCI；
  • NVMe-MI 是其面向 BMC 带外管理的子规范。openUBMC 通过 storage/src/lualib/nvme/nvme_mi_protocol/ 实现 NVMe-MI 协议栈，借助 mctpd 完成报文传输，覆盖 SMART、固件、Telemetry 一键收集等场景；
  • 在不同物理形态上承载，常见的有 M.2、U.2/U.3、AIC、EDSFF、CFexpress 等。

掌握上述三个知识点以及它们在代码中的对应位置，可以帮助新开发者在适配新的硬盘背板、新型号 NVMe SSD 时快速定位需要修改 / 扩展的代码模块。建议与 硬盘背板开发指南、硬盘管理手册、RAID 卡适配指导、mctpd 使用说明 等文档配合阅读，形成 openUBMC 存储域的完整知识地图。