SOLdump（systemcom）是否属于非易失性存储？bmc重启后旧日志会被清空吗？

Interface SIG
1

想咨询一下 openUBMC 中 SOL dump / systemcom 的实现机制，重点是它是否属于非易失性存储，以及 BMC 重启后的保留行为。

我这边通过 Redfish 测试的接口是：

  • ExportSerialPortData
  • 路径：
    /redfish/v1/Managers/1/DiagnosticService/Actions/DiagnosticService.ExportSerialPortData

导出后得到的是 sol_dump.tar.gz，里面是 systemcom.dat。

目前我的测试现象如下：

  1. DiagnosticService 中可以看到：
  • SerialPortDataEnabled = true
  • SerialPortDataSize = 2097152

  1. 导出的 systemcom.dat 大小大约 2MB，里面能看到 BIOS 和部分 kernel 日志。

  2. 在服务器发生新的启动后，再次导出 systemcom.dat，旧日志内容会被新的启动日志覆盖一部分。

  3. 更关键的是，我这边观察到：

  • 在 BMC 重启之后，再导出 SOL dump，之前的旧日志看起来被清空或被新的内容替换掉了
  • 从现象上看，不像是稳定保存在真正的非易失性区域中

所以想确认几个问题：

  1. SOL dump / systemcom 是否设计上属于非易失性存储？
  2. SerialPortDataSize=2097152 是否就是实际的 SOL 环形缓冲区大小？
  3. 当日志区写满以后，覆盖机制是否为 FIFO？
  4. “非易失性保存 SOL 日志”的定义，是否包括 BMC 重启后日志仍然保留？
  5. 如果 BMC 重启后 systemcom 日志丢失，这是否是已知限制、当前实现如此，还是异常行为？
2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结与建议

问题 回答
SOL/systemcom 是否为非易失性存储？ :cross_mark: 否，基于内存的环形缓冲区，易失性。
SerialPortDataSize 是否为缓冲区大小？ :white_check_mark: 是，2097152 = 2MB，即 buffer 容量。
写满后是否 FIFO 覆盖？ :white_check_mark: 是，先进先出，循环覆盖。
非易失性是否应包含重启后保留？ :white_check_mark: 是，但从实现角度看，SOL 不满足该标准。
BMC 重启后日志清空是否异常？ :cross_mark: 否，属于当前机制下的正常行为。
点击此处查看详细分析解答

关于 openUBMC 中 SOL Dump（systemcom）的存储机制与持久性分析

根据您的问题和测试现象，结合知识库中的信息，以下是对 SOL Dump / systemcom 在 openUBMC 中实现机制的详细解答。

:small_blue_diamond: 1. SOL Dump / systemcom 是否属于非易失性存储？

结论：否，SOL Dump（systemcom.dat）本质上是基于易失性内存的环形缓冲区（Circular Buffer）实现，不属于真正意义上的非易失性存储。

分析依据：

  • 文档中明确提到：

    “串口数据保留的是系统串口输出的最近2MB的数据。”
    —— 来自文档片段 3938 的“系统串口数据记录功能”描述。

  • 此行为符合 UartCircularLog 的典型特征，而知识图谱中 BMC Serial Log 的描述指出：

    “BMC Serial Log is a system log feature that uses similar principles to UartCircularLog for serial data collection.”

这表明 systemcom.dat 是通过环形缓冲区机制在内存中动态收集的串行日志数据，其目的是保留最近一段时间的输出内容（如 BIOS 启动、内核日志等），而非长期持久化保存。

因此，尽管该日志在服务器正常运行期间看起来像是“保存”了数据，但它并未设计为在 BMC 断电或重启后持续存在的非易失性存储。

:small_blue_diamond: 2. SerialPortDataSize = 2097152 是否就是实际的 SOL 环形缓冲区大小？

结论：是的，SerialPortDataSize = 2097152 表示环形缓冲区大小为 2 MiB（约 2MB），对应实际的 systemcom.dat 文件大小。

支持证据：

  • 您的测试中导出的 systemcom.dat 大小约为 2MB，与 SerialPortDataSize = 2097152 完全吻合。
  • 其他案例中也提到了：

    “串口数据保留的是系统串口输出的最近2MB的数据。”
    —— 来自用户反馈和 Web 界面说明。

此数值即代表缓冲区上限，一旦填满即开始覆盖旧数据，典型应用于诊断场景下的最近行为追溯。

:small_blue_diamond: 3. 当日志区写满后，覆盖机制是否为 FIFO？

结论：是，其覆盖机制遵循 FIFO（先进先出）原则，符合环形缓冲区（Circular Buffer）的行为逻辑。

说明：

  • 虽然知识库中未明确提及“FIFO”，但 环形缓冲区的本质就是当缓冲区满时，新写入的数据会从头部覆盖最老的数据。
  • 用户观察到的现象——“新的启动日志覆盖一部分旧日志”——正是该机制的体现。

此外，类似机制在嵌入式系统中广泛用于串口调试日志（如 UartCircularLog），目标是高效利用有限内存空间，保留最新运行轨迹。

:small_blue_diamond: 4. “非易失性保存 SOL 日志”的定义，是否包括 BMC 重启后日志仍保留？

结论：从严格意义上看，“非易失性保存”应当包含 BMC 重启、掉电后的日志保留；但当前 SOL Dump 的实现不满足此定义。

详细解释：

  • 真正的非易失性日志机制（如 SEL、Maintenance Log、Blackbox）通常会：

    • 将关键事件写入 Flash 或专用存储芯片；
    • 支持跨 BMC 复位甚至 AC 重启的数据保留；
    • 使用如 SQLite、持久化文件系统（pram, datafs）等机制保障数据生存周期。

  • 而 SOL/systemcom 属于运行时诊断日志，其特点为：

    • 内存驻留（RAM-based）；
    • 高频读写、低延迟采集；
    • 不保证跨重启/掉电的完整性。

因此，BMC 重启后 systemcom.dat 被清空或重置，是当前设计行为，而非异常故障。

:small_blue_diamond: 5. BMC 重启后旧日志丢失是否属于已知限制？是否为异常？

结论：这是当前设计的正常行为，属于已知机制限制，并非异常或 Bug。

佐证信息：

  • 多项日志（如 app.log, framework.log, maintenance.log）被明确用于诊断 BMC 重启相关行为，但 systemcom.dat 并不在其中。
  • 存在专门的 Blackbox 功能用于保存故障前的关键状态：

    “黑匣子存储器是系统内置的用于记录故障信息的存储芯片，不依赖于服务器的硬盘，开启黑匣子功能依赖PCIe接口开启。”
    —— 来自文档 3938

这说明，openUBMC 区分了两类日志：

类型 示例 是否跨重启 存储介质
易失性运行日志 systemcom.dat（SOL） :cross_mark: 否 内存缓冲区
非易失性诊断日志 SEL、Blackbox、Maintenance.log、app.log :white_check_mark: 是 Flash / NVMe / datafs

因此可以得出：

:white_check_mark: systemcom.dat 在 BMC 重启后丢失是符合设计预期的
:warning: 若需在 BMC 重启后仍保留串口日志，应启用其他机制（如下述建议）

:white_check_mark: 总结与建议

问题 回答
SOL/systemcom 是否为非易失性存储？ :cross_mark: 否，基于内存的环形缓冲区，易失性。
SerialPortDataSize 是否为缓冲区大小？ :white_check_mark: 是，2097152 = 2MB，即 buffer 容量。
写满后是否 FIFO 覆盖？ :white_check_mark: 是，先进先出，循环覆盖。
非易失性是否应包含重启后保留？ :white_check_mark: 是，但从实现角度看，SOL 不满足该标准。
BMC 重启后日志清空是否异常？ :cross_mark: 否，属于当前机制下的正常行为。

:hammer_and_wrench: 建议解决方案（如需持久化串口日志）

若您需要实现 跨 BMC 重启的串口日志保留，可考虑以下替代或补充机制：

  1. 启用 Blackbox 日志功能

    • 利用 PCIe 接口连接的独立黑匣子存储芯片；
    • 命令：ipmget -d blackbox（需授权用户执行）

  2. 定期导出 SOL 日志至外部系统

    • 通过 Redfish 接口自动化导出 ExportSerialPortData；
    • 在 BMC 重启前主动保留现场快照。

  3. 使用 Maintenance Log 或 app.log 进行事件关联

    • app.log 和 maintenance.log 支持持久化；
    • 可记录串口采集服务的启停、错误等元信息。

  4. 自定义日志落盘脚本

    • 将 systemcom.dat 导出后自动上传至 NFS/SCP/S3 等远程存储；
    • 实现近似“持久化”的效果。

如未来版本需要增强 SOL 的持久性，建议推动将 systemcom 缓冲区扩展支持写入 复位持久化（ResetPer） 或 掉电持久化 区域（如 pram 或 datafs），但这会增加对 NAND Flash 的写入负担，需权衡寿命与实用性。

3

上面有一点错误，BMC重启没事，但是系统上下电会把日志清空