SATA HDD盘HGST厂商显示为HUAWEI

weixin_41256007 · 2026 年4 月 29 日 03:50

问题描述

硬盘热插拔测试中出现插入HGST的盘厂商确显示HUAWEI

通过研究发现持久化的数据中写入了错误的数据，导致从持久化数据中加载了错误的厂商

想了解下硬盘持久化数据写入的机制，什么情况会触发数据持久化？如何解决这个问题

环境信息

操作系统：openEuler
软件版本：2512
硬件配置：HGST HUAWEI

ubmc_assistant · 2026 年4 月 29 日 03:53

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

总结

项目	内容
问题本质	持久化机制复用了错误的厂商信息，导致设备识别错误
核心机制	硬盘信息在首次识别后写入掉电持久化数据库，后续插拔直接加载
主要风险	一次错误识别会导致长期错误显示，影响运维判断
解决措施	手动清理持久化数据 + 优化识别逻辑 + 增加校验机制
长期改进	实现智能刷新策略，加强数据合法性校验，完善日志追踪

行动建议：立即清理当前错误记录，并在后续版本中实现基于 设备状态（Spun-up）+ 厂商合法性校验 的增强识别机制，从根本上杜绝此类问题。

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

SATA HDD硬盘厂商信息持久化异常问题分析与解决方案

问题概述

在对HGST品牌的硬盘进行热插拔测试时，系统错误地将其厂商信息显示为"HUAWEI"，而非正确的"HGST"。经排查发现，该问题是由于持久化存储（Persistent Data）中记录了错误的厂商信息，导致系统在插入硬盘时直接从数据库加载了错误数据，而未重新获取真实设备信息。

硬盘持久化数据写入机制详解

数据持久化流程

根据知识库及系统设计规范，硬盘信息的持久化机制如下：

持久化触发条件
- 当硬盘首次插入并完成初始化后，系统会采集其基本信息（包括序列号、型号、厂商等）。
- 这些数据通过 Persistent_Data 机制保存至数据库中，用于后续快速加载。
- 持久化操作通常由设备识别模块在 on_add_drive_call_back 函数中完成。
数据来源与写入时机
- 厂商信息来自以下途径：
  - 直接从硬盘SATA IDENTIFY数据读取
  - RAID卡返回信息（如显示为ATA，表示RAID卡未解析出厂商名）
- 若当前环境下 RAID 卡无法正确返回厂商信息（例如在 Spun-down 状态下），系统可能依赖历史或默认值进行填充。
- 一旦写入持久化数据库，后续插拔将优先使用该缓存数据。
持久化类型
- 使用的是 掉电持久化（Power-off Persistence） 机制，数据存储于 /data/trust/persistence/per_poweroff.db。
- 支持在 BMC升级、重启、AC断电 后保留数据，但会在恢复出厂设置或Flash擦写时清除。
防止重复写入逻辑
- 在 raid下硬盘同时拔出和插入 的场景中，代码逻辑如下：
```
if existing persistent data found then
    do not update disk info
else
    fetch and save real-time disk information
end
```
- 即：只要数据库中存在对应序列号或位置的持久化数据，就不会重新查询真实设备信息。

问题根因分析

根本原因

持久化数据库中写入了一条错误映射：HGST硬盘的序列号 V3HG8HPN 被错误地标记为厂商 “HUAWEI”，此后每次插入该盘都会复用此错误数据，导致厂商信息始终显示为HUAWEI。

可能的触发场景

结合文档上下文和系统行为，可能的原因包括：

原因	说明
1. 初始化时错误识别	初始插入该硬盘时，RAID卡或驱动未能正确获取厂商信息，系统误判为华为盘，或将未知厂商默认映射为"HUAWEI"。
2. RAID卡返回信息误导	SATA硬盘处于特殊状态（如Spun-down或RAID初始化未完成）时，RAID卡返回厂商为"ATA"，此时系统尝试通过OUI或历史匹配补全厂商名，产生误匹配。
3. 编码映射表错误	厂商OUI映射表中可能存在配置错误，将某个硬件特征（如控制器ID）错误关联到"HUAWEI"。
4. 测试过程人工干预导致污染	曾手动修改过某条盘的信息并持久化，后续未清理导致污染扩散。

参考知识库中类似问题：

“Raid卡下的SATA HDD硬盘厂商显示ATA”案例指出，Spun-down状态下RAID卡只返回厂商为ATA。

解决方案是：仅在Spun-up状态下发送直通命令主动查询真实厂商信息。

解决方案

1. 清理错误的持久化数据（推荐立即执行）

方法一：手动清除特定硬盘的持久化记录

# 登录BMC系统，进入持久化数据库目录
cd /data/trust/persistence

# 备份原始数据库（重要！）
cp per_poweroff.db per_poweroff.db.bak

# 使用SQLite工具打开数据库
sqlite3 per_poweroff.db

# 查找含有该硬盘序列号或错误厂商的数据
SELECT * FROM properties WHERE value LIKE '%V3HG8HPN%' OR value LIKE '%HUAWEI%';

# 删除相关错误记录（示例）
DELETE FROM properties WHERE key LIKE '%SerialNumber%' AND value='V3HG8HPN';
DELETE FROM properties WHERE key LIKE '%Manufacturer%' AND value='HUAWEI';

# 退出并重启BMC服务
.quit

方法二：清除整个磁盘类持久化数据（影响范围更大）

# 清空所有硬盘相关的持久化属性
rm /data/trust/persistence/per_poweroff.db
# 系统会在下次启动时重建数据库，并重新采集真实信息

建议：先尝试方法一精确清理，避免影响其他设备。

2. 修改系统逻辑避免同类问题复发

方案一：强制刷新机制（适用于高可靠性场景）

引入参数控制是否强制忽略持久化数据并重新读取设备信息：

-- 伪代码示例
function on_add_drive(drive)
    local serial = drive.SerialNumber
    local persisted_data = get_persistent_data(serial)

    -- 强制刷新标志（可通过配置项开启）
    if config.FORCE_REFRESH_DISK_INFO or not persisted_data then
        real_info = get_real_disk_info_from_identify()
        update_persistent_data(real_info)
    else
        use_persisted_data(persisted_data)
    end
end

方案二：增加厂商合法性校验

在写入持久化前验证厂商名与序列号/型号是否合理匹配：

-- 示例规则校验
function validate_manufacturer(model, manufacturer)
    local prefixes = {
        HGST = "HU",
        SEAGATE = "ST",
        WESTERN_DIGITAL = "WD",
        SAMSUNG = "MZ",
        TOSHIBA = "MK"
    }

    for prefix, expected_manufacturer in pairs(prefixes) do
        if string.sub(model, 1, 2) == prefix then
            return manufacturer == expected_manufacturer
        end
    end
    return true -- 未知型号绕过
end

如检测到 Model=HUS726T4TALA600 却 Manufacturer=HUAWEI，则拒绝写入持久化。

方案三：仅在Spun-up状态执行厂商识别

参考知识库中的最佳实践：

“为了防止误唤醒硬盘，只有在 spun-up 状态下的硬盘才会发送直通命令获取厂商信息。”

因此应确保：

系统仅在盘进入 Spun-up 状态后才尝试读取真实厂商信息；
若为 Spun-down 状态，可暂标记为未知，不写入持久化或标记为待更新。

预防建议

措施	说明
新硬盘上线前先格式化持久化数据	对测试机或新部署系统，首次加载前清空 `/data/trust/persistence/*` 防止污染。
建立厂商-OUI映射白名单	在代码中维护正规厂商映射表，禁止无映射的厂商名写入。
日志中记录持久化写入事件	增加日志打印，如：`Disk[V3HG8HPN] manufacturer 'HUAWEI' saved to persistence`，便于审计。
支持一键刷新硬盘信息接口	提供Redfish或CLI命令强制重新识别指定硬盘。

总结

项目	内容
问题本质	持久化机制复用了错误的厂商信息，导致设备识别错误
核心机制	硬盘信息在首次识别后写入掉电持久化数据库，后续插拔直接加载
主要风险	一次错误识别会导致长期错误显示，影响运维判断
解决措施	手动清理持久化数据 + 优化识别逻辑 + 增加校验机制
长期改进	实现智能刷新策略，加强数据合法性校验，完善日志追踪