bazel: bazel build data is huge and takes several hours to remove
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 领域
- build-system
调研方向
Start by reviewing the Bazel cache and output-directory settings listed in the issue, especially --output_user_root, --output_base, --repository_cache, and --disk_cache. The report does not identify which directories are duplicated or what is making removal slow, so first gather disk-usage and file-permission details for those paths. Done means identifying a reproducible cause and a concrete way to reduce disk usage or simplify cleanup.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
I had to move data to another bigger drive. This took several hours.
I tried using rm -rf -v to see what was happening and it seems there are a lot of duplicates directories.
Also I had to do chmod -R u+w as there was a lot of files that was readonly.
I used the following directories:
root=/prj/gpca_dig/users/costa/.bazel
mkdir -p $root/output/user_root
mkdir -p $root/output/base
mkdir -p $root/cache/repository
mkdir -p $root/cache/disk
with the following in the ~/.bazelrc file:
startup --output_user_root=/prj/gpca_dig/users/costa/.bazel/output/user_current
startup --output_base=/prj/gpca_dig/users/costa/.bazel/output/base
common --repository_cache=/prj/gpca_dig/users/costa/.bazel/cache/repository --disk_cache /prj/gpca_dig/users/costa/.bazel/cache/disk
fetch --repository_cache=/prj/gpca_dig/users/costa/.bazel/cache/repository --disk_cache /prj/gpca_dig/users/costa/.bazel/cache/disk
build --repository_cache=/prj/gpca_dig/users/costa/.bazel/cache/repository --disk_cache /prj/gpca_dig/users/costa/.bazel/cache/disk
run --repository_cache=/prj/gpca_dig/users/costa/.bazel/cache/repository --disk_cache /prj/gpca_dig/users/costa/.bazel/cache/disk
test --repository_cache=/prj/gpca_dig/users/costa/.bazel/cache/repository --disk_cache /prj/gpca_dig/users/costa/.bazel/cache/disk
Expected Behavior
Reduce disk usage
Environment
RHEL 8.1
Latest OR
To Reproduce
/
Relevant log output
Screenshots
No response
Additional Context
No response
- 主要语言
- Verilog
- 星标
- 3.3k
- 派生
- 1.1k
- 平均合并
- 2 天 14 小时
- 30 天内合并 PR
- 277
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
The-OpenROAD-Project/OpenROAD 的其他 Issue
-
bazel enhancement
难度 1/5 1 小时以内 新手友好度 76/100
The-OpenROAD-Project/OpenROAD#12160 · 1 条评论 ·
维护者通常 1 天内回复
-
odb: Bazel build fails on linux/aarch64 — char fc compared to EOF in def/lef lexers可能已有人在做 @shivarammysore 于 4 天前认领。 未关闭bazel bug odb
难度 1/5 1 小时以内 新手友好度 80/100
The-OpenROAD-Project/OpenROAD#12095 · 2 条评论 ·
维护者通常 1 天内回复
-
OpenRCX: extMeasure::calcRes0 segfaults on a null getRes() result when a rules file has sparse per-layer tables可能已有人在做 @AcKoucher 于 5 天前认领。 未关闭bug rcx
难度 2/5 1-3 小时 新手友好度 78/100
The-OpenROAD-Project/OpenROAD#12052 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
syn: acd_resynth -apply segfaults on a database resynthesized in an earlier process可能已有人在做 @povik 于 3 天前认领。 未关闭bug syn
难度 2/5 1-3 小时 新手友好度 77/100
The-OpenROAD-Project/OpenROAD#12046 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
check_placement: padding check flags a legal cell above a fixed block whose bottom is in the upper half of a row可能已有人在做 @gudeh 于 5 天前认领。 未关闭bug dpl
难度 2/5 1-3 小时 新手友好度 78/100
The-OpenROAD-Project/OpenROAD#12038 · 3 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 The-OpenROAD-Project/OpenROAD 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
NVIDIA windows
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
good first issue help wanted
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
The docs build fails: ecc's live inventory dropped the ecc.ecc names btclib's pinned ecc uses可能已有人在做 @fametrano 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
btclib-org/btclib#2968 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复