Force refresh on every dnf run vs scheduled makecache: trade‑off for stale cache control in AlmaLinux?

Answer

For AlmaLinux, enabling metadata_expire=0 (or using dnf --refresh) forces DNF to download fresh repository metadata on every invocation, guaranteeing zero‑staleness but incurring a download of the full metadata set each time. A scheduled dnf makecache timer updates the metadata at a fixed interval (e.g., every 6 h, 12 h, or daily), trading a bounded staleness window for reduced bandwidth.

Confirmed facts

• DNF treats metadata as stale after the value of metadata_expire (default 6 h).
• Setting metadata_expire=0 makes every dnf command treat the cache as expired, triggering a refresh.
• The dnf-makecache.timer unit, when enabled, runs dnf makecache on the schedule defined in its timer unit.
• Metadata size for a typical AlmaLinux BaseOS repo is on the order of a few megabytes (≈2‑5 MB) per architecture.

Likely explanation / trade‑off

If each metadata refresh transfers ≈ M bytes, then:

• With metadata_expire=0 and N DNF runs per day, daily traffic ≈ N × M.
• With a timer that runs every T hours, daily traffic ≈ (24/T) × M, and the maximum age of metadata is T hours.

Thus the bandwidth saving factor is roughly N ÷ (24/T). For a server that runs DNF only a few times a day (e.g., N = 4) and a 6‑hour timer (T = 6, giving 4 runs/day), the traffic is comparable; for more frequent DNF use (e.g., N = 20) the timer saves about 80 % of the bandwidth.

Staleness risk grows linearly with the timer interval: the chance of encountering a missing or updated package is proportional to how long the metadata lags behind the mirror.

When a hybrid setting helps

If the repository changes infrequently but occasional bursts of updates occur (e.g., security‑only updates released twice a week), a longer metadata_expire (e.g., 12 h) combined with a weekly dnf makecache run can keep bandwidth low while still catching the bulk of changes. The hybrid approach outperforms pure force‑refresh when:

• Metadata size M is relatively large (≥ 5 MB) and network is metered or high‑latency.
• The update frequency of the repo is lower than the chosen timer interval, making frequent refreshes wasteful.

Conversely, if the repo sees multiple changes per day (e.g., rolling‑release or internal development repos), forcing refresh per run or using a short timer (≤ 2 h) is preferable.

Verification steps (optional)

# Check current metadata age
stat /var/cache/dnf/metadata_timestamp-*
# Force a refresh and see the timestamp update
dnf --refresh repolist
stat /var/cache/dnf/metadata_timestamp-*
# Verify timer status
systemctl list-timers --all | grep dnf-makecache

To refine the recommendation, it would help to know the approximate size of the repository metadata you are syncing (M) and how many DNF invocations you expect per day (N).