CDX-301d · Module 2

Disk Quotas & Network Throttling

3 min read

Disk quotas in Firecracker microVMs are enforced at the block device level. The writable overlay has a fixed maximum size — typically 10-20 GB depending on the VM tier. This quota covers everything: the repository clone, installed dependencies, build artifacts, test output, and any temporary files the task creates. When the quota is exhausted, all writes fail with ENOSPC and the task terminates. There is no warning threshold — the first sign of trouble is the error itself.

Network throttling uses tc (traffic control) rules applied to the TAP interface connecting each microVM to the host network. Bandwidth is capped at a fixed rate — typically 100 Mbps for standard tiers — and connection counts are limited to prevent port exhaustion. DNS resolution goes through a host-side resolver that enforces the allowlist: only approved domains (package registries, git hosts) resolve successfully. Requests to non-allowlisted domains receive NXDOMAIN, not a timeout. This fail-fast behavior is intentional — it makes misconfigured network access obvious immediately.

# Disk quota enforcement

Overlay max:       10-20 GB (tier-dependent)
Filesystem:        ext4 on virtio-blk
Quota check:       Block device level (not filesystem)
Exhaustion:        ENOSPC → task fails
Monitoring:        df -h inside task logs

# Network throttling

Bandwidth:         100 Mbps (standard), 1 Gbps (compute)
Connections:       256 concurrent max
DNS:               Host-side resolver with allowlist
Blocked domains:   NXDOMAIN (not timeout)
Egress filtering:  iptables + tc on host TAP

# Common disk consumers
- node_modules:    200 MB – 1.5 GB
- .git:            50 MB – 2 GB (use shallow clone)
- Build artifacts:  100 MB – 5 GB
- Test screenshots: 10 MB – 500 MB

Do This

  • Add `df -h` checks in your task setup to monitor disk usage during development
  • Use shallow clones to minimize .git directory size in cloud tasks
  • Clean build artifacts during long-running tasks to stay under disk quota
  • Test network access patterns locally by resolving against the allowlist before submitting cloud tasks

Avoid This

  • Ignore ENOSPC errors — they mean your task generates more data than the disk quota allows
  • Store large binary assets in the repository — use LFS or external storage
  • Assume network timeouts mean the service is down — check whether the domain is allowlisted first
  • Run bandwidth-intensive operations (large downloads, dataset fetches) without checking the throttle limits