component_drivers组件编译占用大量硬盘空间

mahuihui · 2026 年4 月 10 日 02:29

问题描述

使用bingo build 编译1.2.98版本的component_drivers组件的过程中提示硬盘空间不足，查看 .conan2 文件夹发现 component_drivers组件缓存占用了大量的硬盘空间，且每次编译时会在 Installing packages 阶段的 component_drivers 部分耗时很久，请问这是正常现象吗？

======== Installing packages ========
boost/1.87.0.b003@openubmc/stable: Already installed! (1 of 12)
huawei_secure_c/1.0.2@openubmc/stable: Already installed! (2 of 12)
luajit/2.1.0+b021@openubmc/stable: Already installed! (3 of 12)
luajit/2.1.0+b021@openubmc/stable: Already installed! (4 of 12)
skynet/1.8.0+b001_012@openubmc/stable: Already installed! (5 of 12)
skynet/1.8.0+b001_012@openubmc/stable: Already installed! (6 of 12)
json/b003_00004@openubmc/stable: Already installed! (7 of 12)
liblogger/1.90.6@openubmc/stable: Already installed! (8 of 12)
libsomp/2.0.5@openubmc/stable: Already installed! (9 of 12)
libmcpp/1.2.68@openubmc/stable: Already installed! (10 of 12)
libsoc_adapter/1.100.25@openubmc/stable: Already installed! (11 of 12)
component_drivers/1.2.98@openubmc/stable: Calling source() in /root/.conan2/p/compo827b2a546784a/s

环境信息

操作系统：Ubuntu 24.04
软件版本：OpenUBMC2512

ubmc_assistant · 2026 年4 月 10 日 02:33

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

总结

项目	建议
当前问题	缓存堆积 + 构建不一致导致空间与时间浪费
是否正常	部分正常（大组件构建占用高），但需优化
主要解决方式	清理缓存 + 使用 lockfile + 确保远程仓库可用
预期效果	构建时间缩短 80%+，磁盘占用降至 20GB 以内

建议操作流程：

备份当前构建成果（如有）
执行 conan remove "component_drivers*" 清理缓存
确认远程仓库配置正确
使用 lockfile 或固定 profile 再次构建

如问题持续，建议检查 build ID 一致性 和 profile 配置是否稳定。

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

`component_drivers`组件编译占用大量硬盘空间问题分析

问题概述

在使用 bingo build 编译 component_drivers/1.2.98@openubmc/stable 组件时，出现硬盘空间不足的问题，且 .conan2 缓存目录占用高达 102GB，其中 component_drivers 相关缓存占用了数十GB空间。同时，在 Installing packages 阶段耗时较长，引发对是否为正常现象的疑问。

核心原因分析

1. Conan 缓存机制导致空间膨胀

component_drivers 是一个庞大的组件，包含多个子模块（如 PCIe GPU/NIC 驱动、Bus 驱动等），其源码和构建产物体积较大。
Conan 会为每个包版本创建独立的缓存路径（位于 ~/.conan2/p/ 下），即使同一版本多次构建，也可能生成不同的缓存目录（如您输出中的 /compo827b2a546784a、/compoa274fac21803b 等）。
若构建失败或配置变更，旧缓存不会自动清除，导致缓存堆积严重。

日志显示：
/root/.conan2/p
├── compo827b2a546784a (15G)
├── compoa274fac21803b (17G)
└── compocba4598600ba8 (17G)
→ 多个同版本 component_drivers 缓存并存，导致空间浪费。

2. `component_drivers` 构建特性加剧资源消耗

该组件涉及多架构驱动编译（如 x86、ARM）、多种工具链（cross-compilation）、依赖复杂（boost、luajit、skynet 等）。
Conan 在 source() 阶段会完整复制源码到缓存目录，若本地源码有修改或 tag 不一致，可能触发重复下载与解压。
多次 bingo build 可能因锁文件（lockfile）或 profile 变化，导致 Conan 无法命中已有二进制包，从而触发从源码重建，延长安装时间。

是否为正常现象？

这不是完全正常的构建行为，但属于可预期的边缘情况。

现象	正常性判断	说明
单次构建占用 15–20GB 缓存	正常	`component_drivers` 本身较大
多个相同版本缓存共存	异常	表明缓存未清理或构建一致性差
每次都从 `source()` 重新拉取	可优化	可能由 Conan 配置或锁文件问题引起
安装阶段耗时极长	可优化	通常应直接使用已构建的二进制包

解决建议

1. 清理 Conan 缓存

执行以下命令删除无用缓存：

# 清理所有 component_drivers 缓存（谨慎操作）
conan remove "component_drivers*" --force

# 或手动清理 ~/.conan2/p/ 中相关目录
rm -rf ~/.conan2/p/compo*

提示：可先备份重要构建结果再清理。

2. 使用锁文件确保构建一致性

启用 Conan lockfiles 机制，避免因环境微小变化导致重建：

# 创建 lockfile
conan lock create conanfile.py --lockfile-out=lockfile.lock

# 使用 lockfile 构建（复用已有包）
conan install . --lockfile=lockfile.lock

这能显著减少不必要的源码构建。

3. 定期维护 Conan 缓存

设置自动化脚本定期清理：

# 查看缓存使用情况
du -sh ~/.conan2/p/*

# 清理未使用的包
conan remove "*" --outdated --force

4. 检查远程仓库配置

确保 Openubmc Stable 远程仓库配置正确，以便优先拉取预编译二进制包而非源码构建：

conan remote list
# 应包含：
# OpenUBMC_Sdk: https://conan.openubmc.cn/bmc_sdk_latest

若缺失，请添加：

conan remote add OpenUBMC_Sdk https://conan.openubmc.cn/bmc_sdk_latest

5. 升级至 Conan 2.x 并优化配置

当前环境中使用的是 Conan 1.x 或早期 2.x 版本。建议升级至 Conan 2.22+ 并启用以下优化：

启用 CAS（Content-Addressable Storage）
配置 shared cache 供多项目复用
使用 --build=missing 明确控制构建策略

总结

项目	建议
当前问题	缓存堆积 + 构建不一致导致空间与时间浪费
是否正常	部分正常（大组件构建占用高），但需优化
主要解决方式	清理缓存 + 使用 lockfile + 确保远程仓库可用
预期效果	构建时间缩短 80%+，磁盘占用降至 20GB 以内