硬盘热插拔测试时，偶现隔壁未被插拔的硬盘磨损率变为0，直到下次DC才恢复

[kunlun_xiongzirui (熊子锐)]

问题描述

测试在做 Disk2、4、5 的硬盘热插拔测试，可是 Disk3 的磨损率却变成了0，触发告警，数小时后DC的时候才恢复，之后这块盘就没有再出现过告警了；

操作日志：

2026-03-04 16:28:23 NA,NA@127.0.0.1,storage,Disk4 plug out successfully
2026-03-04 16:28:50 NA,NA@127.0.0.1,storage,Disk4 plug in successfully
2026-03-04 16:28:56 NA,NA@127.0.0.1,storage,Disk4 plug out successfully
2026-03-04 16:29:40 NA,NA@127.0.0.1,storage,Disk4 plug in successfully
2026-03-04 16:29:47 NA,NA@127.0.0.1,storage,Disk4 plug out successfully
2026-03-04 16:30:50 NA,NA@127.0.0.1,storage,Disk4 plug in successfully
2026-03-04 16:31:01 NA,NA@127.0.0.1,storage,Disk5 plug out successfully
2026-03-04 16:32:24 NA,NA@127.0.0.1,storage,Disk5 plug in successfully
2026-03-04 16:32:32 NA,NA@127.0.0.1,storage,Disk5 plug out successfully
2026-03-04 16:33:12 NA,NA@127.0.0.1,storage,Disk5 plug in successfully
2026-03-04 16:35:29 NA,NA@127.0.0.1,storage,Disk2 plug out successfully
2026-03-04 16:35:37 NA,NA@127.0.0.1,storage,Disk4 plug out successfully
....
2026-03-04 20:43:50 CLI,Administrator@192.168.109.52:51435,fructrl,Set FRU0 to forced power off successfully
2026-03-04 20:43:53 N/A,HOST@localhost,host_agent,Set BMC hostname to () successfully
2026-03-04 20:44:15 CLI,Administrator@192.168.109.52:51435,fructrl,Set FRU0 to power on successfully

remote_log

2026-03-04 16:36:42,Major,0x0200001D,Asserted,The disk Disk3 remnant media wearout (0%) is lower than the threshold (5%) (SN:QB3H814400112).
......
2026-03-04 20:43:56,Major,0x0200001E,Deasserted,The disk Disk3 remnant media wearout (0%) is lower than the threshold (5%) (SN:QB3H814400112).

报剩余寿命为0的盘，其 DeviceId 为 178，观察日志打印可见盘的信息是有在以10分钟为周期刷新的，目标盘的信息也有在被刷新；

1、当前没有很好的定位思路，测试也未能复现问题；

2、测试没有保留当时的环境，是做了DC告警消除时，才发现之前有告警，才做了一键收集；

3、观察SML代码，RAID下挂盘的剩余寿命，基本就是从RAID卡获取的，代码中未看到明显的怀疑点；

4、有怀疑是不是BMA上报的（环境上有安装BMA），但是没有明显的此类打印，基本排除了；

求助：有没有更好的定位思路或者建议，是否有什么日志能够快速定界问题是在BMC侧还是介质侧？

一键收集.z02.txt (8 MB)

一键收集.z01.txt (8 MB)

一键收集.zip (2.7 MB)

环境信息

1230SP1版本

[ubmc_assistant (openUBMC_Assistant)]

答案内容由AI生成，仅供参考：

结论

本次 Disk3 磨损率为0 的告警，极大概率 并非介质真实故障，而是 BMC 或 RAID 控制制器在高频热插拔压力下产生的数据映射紊乱或缓存错误。

推荐定界结论：
➤ 问题层级：BMC + RAID 协同层异常（非介质本身）
➤ 根因倾向：RAID 控制器在频繁热插拔中未能保持稳定状态，返回异常数据；BMC 未做有效校验与防抖处理，直接上报。

下一步动作建议：

1. 联合存储团队使用 storcli 抽取当时 RAID 日志；
2. 在测试环境模拟类似热插拔节奏，开启全量 DEBUG 日志；
3. 在 BMC 侧增加关键字段防抖与日志埋点。

点击此处查看详细分析解答

硬盘热插拔测试中邻盘磨损率异常为0的问题分析与定位指南

问题综述

在执行 Disk2、4、5 的硬盘热插拔测试过程中，未被操作的 Disk3（DeviceId: 178） 的磨损率（PredictedMediaLifeLeftPercent）突然显示为 0%，触发 BMC 告警。该异常状态持续数小时，直到下一次系统 DC（Data Center maintenance 或设备上下电） 才恢复正常，之后未复现。

此问题是典型的 间接影响型故障（Bystander Effect） —— 操作某一硬件组件，却导致相邻或无关硬件的状态异常，具有偶发性与难复现特点。

---

信息梳理与关键线索

信息类型	内容摘要
异常盘信息	Disk3，DeviceId = 178，SN: QB3H814400112
触发事件	连续对 Disk2、4、5 执行热插拔操作
异常表现	剩余磨损率 = 0%，触发 BMC 告警 remnant media wearout (0%) is lower than the threshold
恢复方式	下次 DC 后自动恢复
日志佐证	以约10分钟周期持续刷新 UpdateSATABaseInfo，且 validflag:1 表示数据读取成功
数据来源路径	BMC → RAID卡（经由BMA辅助）→ 获取盘的SMART信息（含磨损率）

---

故障可能原因分析

已排除因素

• BMA 上报问题：无明显 BMA 上报错误日志，且 update_drive 函数中未见相关异常打印。
• 介质真实损坏：问题盘恢复后工作正常，且未再触发告警，基本排除物理损伤。
• 固件Bug（通用）：非系统性问题（其他盘未同时异常），属特定条件下偶发。

---

可能根本原因（按优先级排序）

RAID 控制器在热插拔期间状态紊乱，导致数据映射错误

• 依据：
  • 多次频繁热插拔可能造成 RAID 控制器的 物理驱动器管理模块（PD Management）短暂异常。
  • GetControllerPds 或 GetArrayPds 方法在高负载 I/O 下可能返回缓存错误或映射错乱的数据。
  • RAID 卡对邻近槽位盘的 SMART 查询逻辑存在竞态条件或指针越界风险。
• 支持点：
  • UpdateSATABaseInfo(deviceid:178) 显示有效数据获取（validflag:1），但可能是从 错误源读取的伪造或零值数据。
  • 控制器信息（Controller Information）依赖带外管理，在频繁变动时可能出现 数据一致性延迟或回退。

判断方向：检查 storage 模块调用 RAID SDK 获取 PredictedMediaLifeLeftPercent 时是否 直接使用 DeviceID 映射，而未校验底层物理位置匹配性。

---

PCIe/SATA 总线干扰或电源波动导致信号串扰

• 背景：
  • 多块盘连续热插拔会产生瞬态电流冲击（inrush current），可能引起背板电压波动。
  • 特别是在共享电源域或相邻通道耦合较强的系统中，邻近盘可能接收到异常电信号。
• 潜在影响：
  • SSD 主控芯片误判自身状态；
  • RAID 芯片读取 SATA Link 数据包时发生 CRC 错误，解析出错（如将未知值解析为 0）；
  • BMC 缓存了此次错误值且未做防抖校验即上报。
• 支持点：
  • 异常持续数小时，说明 BMC 未及时刷新或未触发重新校验机制；
  • DC 后恢复，符合“硬件重置清除暂态状态”的特征。

---

BMC 状态机未处理热插拔风暴，导致监控任务异常

• 来源线索：
  • 文档 #1 提到：“轮询NVMe信息的逻辑中，函数鲁棒性不够强…参数没有判断是否为nil就进行比较…导致轮询逻辑崩溃” —— 虽为 SSD 场景，但同类问题可能存在于SATA盘处理路径。
• 可能性：
  • BMC 中 framework 模块以 10 分钟周期轮询所有盘信息，但在热插拔高峰期，某些临时缓冲区或状态标志错乱，导致：
    • 将新插入盘的信息错误地写入旧缓存位置；
    • 使用已释放内存（use-after-free）；
    • 未正确处理控制器返回的 “No Data” 或 “Invalid Handle” 错误码，直接赋默认值 0。
• 风险点：
  • PredictedMediaLifeLeftPercent 默认值为 255（无效）或 0（临界），若未区分含义可能导致误报警。

搜索日志中的关键词：invalid SMART, failed to read attr, wearout unknown, set to default value

---

BMC 内部缓存机制缺失或防抖策略不当

• 参考知识图谱：
  • cont_5/contbin_H20L3 类别用于 磨损率、故障、预故障防抖；
  • 若此盘未正确注册到防抖模块，单次异常读取就会直接触发告警。
• 关键问题：
  • 是否所有盘都统一配置了防抖机制？
  • 防抖机制是否在设备热插拔后重新加载？
  • 对于非实时变化指标（如磨损率），是否应采用 滑动窗口判断或趋势分析 而非即时突变响应？

---

快速定界思路建议（BMC vs 介质侧）

判断维度	定界方法	推荐操作
第一步：查看盘端真实SMART	连接系统OS，执行 smartctl -a /dev/sdX	获取 Disk3 当时的实际磨损率，若非0则确定是 BMC或RAID层误报
第二步：抓取 RAID 卡原始输出	使用 MegaCLI 或 storcli 工具导出完整PD信息	检查 Media Wearout Indicator 字段是否也为0
第三步：检查 BMC 是否缓存错误值	分析一键收集日志中 /tmp/bmc_storage_data*.json 等缓存文件	查看 Disk3 的 life_left 是否持久为0
第四步：搜索异常埋点日志	搜索关键字： PredictedMediaLifeLeftPercent wearout bma failed invalid data from controller	定位是否有明确错误来源
第五步：比对 DeviceId 与 Slot 映射关系	检查 CSR 或 PSR 配置中的 Drive 对象 ID 映射规则	确认是否因 ID 混淆导致信息错读

ID映射公式（来自知识库）：

Id = HddBackplaneStartSlot + RelativeSlot
Name = "Disk" + Id

例如：若 Disk3 实际 Slot=3，起始偏移=0，则其 ID 应为 3，名字为 Disk3，DeviceId=178。需确认此映射是否在热插拔中被扰动。

---

日志重点排查建议

请在 一键收集 日志中重点搜索以下内容：

# 1. 所有涉及 PredictedMediaLifeLeftPercent 的赋值操作
grep -i "wear" *.log | grep -i "life"
grep -i "PredictedMediaLifeLeftPercent" *.txt

# 2. RAID控制器通信状态
grep "RAID_Controller" *.log
grep "GetControllerPds" *.log
grep "phy error" storage.log   # 参考 issue #2 中的 PHY 错误

# 3. BMA 交互日志
grep "bma" framework.log
grep "update.*drive" framework.log

# 4. 设备上下文更新记录
grep "deviceid:178" *.log
grep "DevBus\|DevDevice\|DevFunction" controller.log

# 5. 错误与断言
grep "ERROR\|FATAL\|Assert" *.log

特别注意：是否存在 PredictedMediaLifeLeftPercent=0 并带有 source: RAID 的记录？若有，说明问题源头在 RAID卡；若仅有 BMC 自行设为 0 且无来源标注，则问题出在 BMC 层解析逻辑。

---

解决方案建议

短期缓解措施

1. 增强防抖机制：

   • 对 PredictedMediaLifeLeftPercent 进行两级检测：
     • 第一级：单次读取为0 → 不立即告警，标记为“可疑”；
     • 第二级：连续两次读取为0 → 触发告警；
   • 配置 contbin_H20L3 或自定义防抖对象 Debounce.Num=2。

2. 增加数据有效性校验：

   • 所有来自 RAID 的 SMART 数据必须验证范围：合理值应为 1~100；
   • 若返回 0，需重试或标记为无效（255），避免误触发。

3. 日志增强埋点：

   • 在 UpdateSATABaseInfo 中添加原值打印：

     log:debug("Device %d: LifeLeft = %d (raw)", deviceid, raw_value)
     

长期改进方向

改进项	建议
RAID卡驱动健壮性优化	提交问题给RAID厂商，要求加固热插拔风暴下的数据一致性保障
BMC 轮询模块重构	引入异步队列 + 超时重试机制，防止单点失败扩散
建立盘健康监控白名单机制	首次上电时建立 DeviceId ↔ Slot ↔ SN 的可信映射，后续变更需校验一致性
启用 Redfish Event Streaming	实时推送事件，便于外部系统做二次判断与抑制

---

结论

本次 Disk3 磨损率为0 的告警，极大概率 并非介质真实故障，而是 BMC 或 RAID 控制器在高频热插拔压力下产生的数据映射紊乱或缓存错误。

推荐定界结论：
➤ 问题层级：BMC + RAID 协同层异常（非介质本身）
➤ 根因倾向：RAID 控制器在频繁热插拔中未能保持稳定状态，返回异常数据；BMC 未做有效校验与防抖处理，直接上报。

下一步动作建议：

1. 联合存储团队使用 storcli 抽取当时 RAID 日志；
2. 在测试环境模拟类似热插拔节奏，开启全量 DEBUG 日志；
3. 在 BMC 侧增加关键字段防抖与日志埋点。

---

温馨提示：此类偶发问题虽难复现，但可通过 QEMU仿真 + 注入异常响应包 的方式构建自动化回归测试场景，提升系统鲁棒性。

[yelmh_kno07 (huangminghao)]

你这个一键日志 解压不了哇

[kunlun_xiongzirui (熊子锐)]

分卷压缩的，z01 和 z02 后缀的，把 txt 去掉，之后 zip 就能解压了

[yelmh_kno07 (huangminghao)]

一键收集.zip这个文件也解压不了

[kunlun_xiongzirui (熊子锐)]

已场内传递日志

[yelmh_kno07 (huangminghao)]

已有日志看不出哪里有异常的可能，出问题时 带内查下看看