rustfs/rustfs · error · ObjectDataCacheConfigError
object data cache could not resolve a positive max capacity
Error message
object data cache could not resolve a positive max capacity
What it means
ObjectDataCacheConfigError::ZeroResolvedMaxBytes is returned by ObjectDataCacheConfig::resolved_max_bytes() (crates/object-data-cache/src/config.rs:165) when max_bytes is left at 0 and the capacity derived from the runtime environment resolves to zero. The derivation is effective (container/cgroup-aware) total memory multiplied by max_memory_percent, then clamped; if the effective memory query reports 0 or the derived value floors to 0, the cache cannot size itself and fails fast instead of starting with no capacity.
Source
Thrown at crates/object-data-cache/src/error.rs:81
/// The configured fill concurrency maximum exceeded the supported range.
#[error("object data cache fill_concurrency_max must be greater than 0")]
ZeroFillConcurrencyMax,
/// The configured fill concurrency bounds are internally inconsistent.
#[error("object data cache fill_concurrency_max must be at least fill_concurrency_per_cpu")]
FillConcurrencyMaxTooSmall,
/// The configured identity key-set cap exceeded the supported range.
#[error("object data cache identity_keys_max must be greater than 0")]
ZeroIdentityKeysMax,
/// A single-key identity budget evicts the previous key on every fill.
#[error("object data cache identity_keys_max must be at least 2")]
IdentityKeysMaxTooSmall,
/// Failed to resolve a non-zero cache capacity from the runtime environment.
#[error("object data cache could not resolve a positive max capacity")]
ZeroResolvedMaxBytes,
}
View on GitHub (pinned to 35af688cd9)
Solutions
- Set an explicit capacity: config.max_bytes = 512 * 1024 * 1024; so resolution never depends on the environment
- Raise max_memory_percent (e.g. to the default) so the derived value is non-zero on the detected total memory
- If running in a container, verify the cgroup memory limit is visible (docker --memory, Kubernetes resources.limits.memory) and not set to 0/unlimited in a way sysinfo reports as zero
- Check that /proc/meminfo and /sys/fs/cgroup are mounted and readable in the runtime environment
Example fix
// before let config = ObjectDataCacheConfig::default(); // max_bytes = 0, derive from memory let cap = config.resolved_max_bytes()?; // Err(ZeroResolvedMaxBytes) on hosts reporting 0 // after let mut config = ObjectDataCacheConfig::default(); config.max_bytes = 512 * 1024 * 1024; // explicit capacity, no env dependency let cap = config.resolved_max_bytes()?; // Ok(512 MiB)
Defensive patterns
Strategy: validation
Validate before calling
// Fail fast with a clear message instead of relying on env detection:
fn resolve_capacity(cfg: &ObjectDataCacheConfig) -> Result<u64, Box<dyn std::error::Error>> {
if cfg.max_bytes == 0 && resolve_effective_memory_total() == 0 {
return Err("environment reports 0 total memory; set max_bytes explicitly".into());
}
Ok(cfg.resolved_max_bytes()?)
} Try / catch
match config.resolved_max_bytes() {
Ok(bytes) => build_cache(bytes)?,
Err(ObjectDataCacheConfigError::ZeroResolvedMaxBytes) => {
// deterministic fallback: explicit capacity, no silent zero-byte cache
let mut fixed = config.clone();
fixed.max_bytes = 256 * 1024 * 1024;
build_cache(fixed.resolved_max_bytes()?)?
}
Err(e) => return Err(e.into()),
} Prevention
- Pin an explicit max_bytes in containers so capacity never depends on cgroup detection
- Smoke-test deployments with a startup probe that calls resolved_max_bytes() and fails fast
- Keep max_memory_percent at sane values (>= 1) and monitor effective-memory detection in new base images
When it happens
Trigger: Calling resolved_max_bytes() (directly or via moka backend construction) with max_bytes == 0 while resolve_effective_memory() returns a total of 0 — e.g. sysinfo cannot read cgroup memory limits, or an extremely small max_memory_percent makes total*percent/100 saturate to 0.
Common situations: Containers with unusual or missing cgroup v2 memory.max; sandboxes/CI where memory detection fails; misconfigured max_memory_percent far below 1% of a tiny total; hosts where /proc or /sys are masked.
Related errors
- object data cache max_entry_bytes must not exceed the resolv
- object data cache max_memory_percent must be in 1..=100
- object data cache max_entry_bytes must be greater than 0
- object data cache max_entry_bytes must stay below 4 GiB so t
- object data cache max_entry_bytes plus weigher overhead must
AI-assisted analysis of rustfs/rustfs@35af688cd9 (2026-08-20).
Data as JSON: /api/errors/3b6f9ccacdc056b6.
Report an issue: GitHub.