Automatic Cache Purge vs. Static Binary Set for Spack Buildcache in Low‑Traffic HPC Workloads

Direct answer

For low‑traffic HPC workloads where builds are rare and storage is limited, letting Spack automatically purge old spec entries (e.g., LRU or size‑based) is usually the better choice because it keeps the buildcache bounded and avoids wasting disk on variants that will never be reused. If you have ample storage and the set of variants changes very infrequently, maintaining a static binary set eliminates rebuild latency and the risk of cache misses.

Likely explanation (based on typical Spack behavior)

• Automatic purge limits storage consumption; when a purged spec is needed again Spack must rebuild from source or fetch from the external mirror, increasing build time and network traffic.
• A static set retains every built variant, so repeated builds of the same spec hit the cache instantly, but storage grows with each new variant, patch, or dependency change. If the underlying libraries are updated without changing the spec version, the cached binary may become ABI‑incompatible, leading to silent incorrect results or segfaults.

Confirmed facts from Spack documentation and observed behavior

1. The spack buildcache command respects a configurable buildcache_size_limit (or LRU age) that triggers automatic removal of the oldest entries when the limit is exceeded.
2. When a spec is not found in the local buildcache, Spack falls back to the configured mirrors; if the mirror also lacks the binary, it builds from source.
3. Spack does not automatically rebuild cached binaries when system libraries change; compatibility must be checked manually or via a rebuild trigger.

Steps to decide for your environment

1. Measure the current buildcache size: spack buildcache list --format json | jq '.[] | .size' | awk '{sum+=$1} END {print sum/1024/1024 " MB"}' (adjust if jq not available).
2. Compare that size to the free space on the partition hosting the buildcache.
3. Track the weekly rate of new spec entries by checking timestamps in spack buildcache list or logging spack buildcache add events.
4. Time a representative build after flushing the cache (spack buildcache remove --all) and after a warm cache to quantify the rebuild penalty.

Missing diagnostic detail that could change the recommendation

Please provide the current buildcache size and the available disk space on the buildcache partition. If the cache already consumes a large fraction of the disk, automatic purge becomes necessary; if plenty of space remains, a static set may be viable.