--- title: "A Pod’s Scratch Volume Shares Its Ephemeral-Storage Budget" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/ai-pod-ephemeral-storage-shared-scratch-accounting" last-updated: "2026-10-21" --- # A Pod’s Scratch Volume Shares Its Ephemeral-Storage Budget Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. Disk-backed emptyDir scratch consumes part of a Pod’s overall ephemeral-storage allowance. For the Kubernetes 1.34 single-filesystem case below, compare each container’s writable layer plus logs with its own limit, then compare the complete Pod usage, including shared scratch once, with the summed container limits. Two containers below their individual limits can still leave the Pod over its aggregate limit. ## Read the container and Pod comparisons together An offer of 3 GiB of scratch alongside container limits of 4 GiB and 2 GiB needs an inclusion statement. Does the supplier mean scratch within the aggregate allowance, or an additional allowance? The accounting below makes that distinction explicit. This article follows Kubernetes 1.34 documentation and a supported single-filesystem local-storage layout with accurate kubelet measurement. It concerns an ordinary, noncritical application Pod whose containers all have explicit ephemeral-storage limits. Init containers, native sidecars and other resource arrangements need their own assessment. In this scope, each container’s comparison uses its writable-layer usage plus its container logs. The Pod comparison uses the combined container usage, disk-backed emptyDir usage and any other included Pod storage charges, against the sum of container limits. Scratch contributes to that second comparison without becoming an extra allowance. References: [K134-ES](https://v1-34.docs.kubernetes.io/docs/concepts/storage/ephemeral-storage/), [K134-IMPL](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go) ## Two individual comparisons pass; the 7 GiB Pod exceeds 6 GiB Consider one fictional Pod with two ordinary containers, A and B, and one shared disk-backed emptyDir. The following usage figures are stipulated accurate accounted usage at the same instant and workload stage. All other Pod storage charges are stipulated zero. These inputs describe an educational example, not an observed workload. A has a 4 GiB ephemeral-storage limit. Its writable layer uses 2 GiB and its logs use 1 GiB, giving 3 GiB of container usage. B has a 2 GiB limit; its writable layer and logs each use 0.5 GiB, giving 1 GiB. The shared emptyDir uses 3 GiB. Here 1 GiB is exactly 1,073,741,824 bytes. The individual comparisons are A: 3 GiB < 4 GiB, and B: 1 GiB < 2 GiB. Both are below their own limits. Together, their writable layers and logs consume 3 + 1 = 4 GiB. The Pod limit is 4 + 2 = 6 GiB. Add the shared volume once: Pod usage is 3 + 1 + 3 = 7 GiB. It exceeds the aggregate limit by 7 − 6 = 1 GiB. A report showing only the two successful container comparisons therefore leaves the decisive Pod comparison unanswered. At the stipulated 4 GiB of container usage, the difference below the 6 GiB aggregate boundary is 2 GiB. Calling the separate 3 GiB scratch figure additional headroom would hide the 1 GiB excess. References: [K134-ES](https://v1-34.docs.kubernetes.io/docs/concepts/storage/ephemeral-storage/), [K134-IMPL](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go), [U1](https://physics.nist.gov/cuu/Units/binary.html) ## One volume mounted twice still contributes 3 GiB Containers in a Pod can access the same emptyDir files through mounts at the same or different paths. In the example, those two mounts expose one shared 3 GiB population. Adding it to each container’s usage and then summing would produce 3 + 3 + 1 + 3 = 10 GiB. That would count the volume twice. A quoted emptyDir sizeLimit is a separate boundary for that volume. It does not increase the 6 GiB Pod limit. Even a proposed 3 GiB volume limit would leave the example’s 7 GiB aggregate usage unchanged. The volume also has a Pod lifecycle: its contents survive a container crash but are deleted when the Pod is removed from the node. The allowance consequently needs both an inclusion statement and the correct lifetime. References: [K134-VOL](https://v1-34.docs.kubernetes.io/docs/concepts/storage/volumes/#emptydir), [K134-IMPL](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go) ## An excess has eviction significance, without a write-time guarantee Under the stated measurement conditions, exceeding a container limit or the aggregate Pod limit leads the kubelet to mark the Pod for eviction. The example crosses the aggregate boundary even though neither container crosses its own. Kubernetes describes periodic usage scans; its filesystem project-quota option monitors usage rather than enforcing limits. These mechanisms do not promise rejection of the exact write that crosses a boundary or an eviction deadline. Directory scans also omit space held by deleted files that remain open. Measurement support matters: the documentation warns that unsupported filesystem layouts can report incorrectly or prevent these limits from being applied. The single-filesystem scope above is deliberate; the upstream 1.34.0 container check varies with filesystem layout. A limit or volume sizeLimit also supplies no evidence of physically preallocated disk. Other users of the backing storage can exhaust it before the volume reaches its own limit. References: [K134-ES](https://v1-34.docs.kubernetes.io/docs/concepts/storage/ephemeral-storage/), [K134-IMPL](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go), [K134-VOL](https://v1-34.docs.kubernetes.io/docs/concepts/storage/volumes/#emptydir) ## Memory-backed emptyDir changes the resource account The example uses disk-backed scratch. An emptyDir with medium Memory is tmpfs: Kubernetes treats its storage as container memory use, and the volume documentation attributes written files to the memory limit of the container that wrote them. A shared mount does not make those files free. That is a different accounting case, requiring its own memory assessment. The related cgroup memory article explains hierarchical host-memory reports. References: [K134-MEM](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/manage-resources-containers/), [K134-VOL](https://v1-34.docs.kubernetes.io/docs/concepts/storage/volumes/#emptydir) ## Get a returned offer that reconciles all three populations A useful supplier return for the original example would say: A contributes 3 GiB of writable-layer and log usage, B contributes 1 GiB, and the shared scratch contributes 3 GiB once. The two limits sum to 6 GiB, so this stated population exceeds that boundary by 1 GiB. That resolves what the offer includes. For a comparison, suppose a second fictional offer instead specifies limits of 4 GiB for A and 4 GiB for B, with the same usage and shared volume. A’s 3 GiB and B’s 1 GiB are each below 4 GiB; the complete 7 GiB is below the new 8 GiB aggregate boundary by 1 GiB. This alternative clears the stated comparisons at that instant. The arithmetic makes the two offers comparable; it does not select suitable limits. Ask the responsible platform supplier to identify the actual filesystem arrangement, measurement basis, concurrent workload stage, container limits, volume boundaries and complete accounted Pod total. Any additional included charges must remain visible. The appointed platform and application owners still need to establish backing capacity and workload suitability. Keep the usage fields tied to that evidence. The linked container pull-size article explains image representations, while the overlay2 article explains retained logical file payloads after copy-up. Neither quantity can replace the accounted usage stipulated here. References: [K134-IMPL](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go) ## Primary sources - [K134-ES — Kubernetes 1.34: Local ephemeral storage](https://v1-34.docs.kubernetes.io/docs/concepts/storage/ephemeral-storage/). Checked 2026-10-21. Versioned definitions of storage populations, supported measurement, summed limits and eviction. Applies here to the stated single-filesystem application Pod. - [K134-VOL — Kubernetes 1.34: Volumes — emptyDir](https://v1-34.docs.kubernetes.io/docs/concepts/storage/volumes/#emptydir). Checked 2026-10-21. Shared files, Pod lifetime, storage medium and volume-size boundaries, including exhaustion of backing storage. - [K134-IMPL — Kubernetes v1.34.0: Local storage eviction checks](https://raw.githubusercontent.com/kubernetes/kubernetes/v1.34.0/pkg/kubelet/eviction/eviction_manager.go). Checked 2026-10-21. Upstream implementation separates volume, aggregate Pod and container comparisons. Container usage treatment depends on filesystem layout; the example uses a single filesystem. - [K134-MEM — Kubernetes 1.34: Resource management — memory-backed emptyDir](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/manage-resources-containers/). Checked 2026-10-21. Explains tmpfs memory accounting and why memory-backed scratch requires a separate memory assessment. - [U1 — NIST: Prefixes for binary multiples](https://physics.nist.gov/cuu/Units/binary.html). Checked 2026-10-21. Defines GiB as 2^30 bytes, distinct from decimal GB. ## Related Leviathan resources - [Separate compressed container pulls from runtime storage](/articles/gpu-container-compressed-layers-versus-runtime-storage) - [Understand classic overlay2 first-write copy-up](/articles/container-overlay2-first-write-copy-up-file-population) - [Read cgroup host-memory charges and event scope](/articles/gpu-host-cgroup-memory-charge-limit-event-scope) - [Scope a separate physical rack-and-stack installation](/services/rack-and-stack) - [Send a separate physical installation inquiry](/contact?service=rack-and-stack&from=%2Farticles%2Fai-pod-ephemeral-storage-shared-scratch-accounting) ## Planning a separate physical equipment installation? Use the rack-and-stack service and project inquiry for that equipment scope. Pod resource policy, storage sizing and runtime operation remain with the appointed platform provider. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/ai-pod-ephemeral-storage-shared-scratch-accounting)