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

  1. Set an explicit capacity: config.max_bytes = 512 * 1024 * 1024; so resolution never depends on the environment
  2. Raise max_memory_percent (e.g. to the default) so the derived value is non-zero on the detected total memory
  3. 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
  4. 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

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


AI-assisted analysis of rustfs/rustfs@35af688cd9 (2026-08-20). Data as JSON: /api/errors/3b6f9ccacdc056b6. Report an issue: GitHub.