Ten images on one host each report 800 MB, yet the host stores far less — why?

## A host stores layers, not images An image is, for storage purposes, an ordered **list of references to layers** plus the metadata that describes it. The layers are the things that occupy disk. Each one is identified by its content, so a host that already holds a layer recognises it when another image references it and keeps a single copy. Ten images that begin from the same base are ten lists that happen to name the same first few entries. That is the whole economy of the format. Lower layers are read-only, which makes them safe to share; they are identified by content, which makes sharing automatic rather than something anyone configures. ## Why per-image sizes double-count A reported image size answers the question "how big is this image?", which has to mean "the total of every layer it references" — the image is not smaller because something else on this host happens to reference the same base. That number is useful for one image and misleading in aggregate, because the moment two images share a layer, both sizes include it. Worked through, with ten images of 800 MB each that all sit on one 700 MB base layer and add 100 MB of their own: | Way of counting | Figure | What it means | |---|---|---| | Sum of reported image sizes | 8000 MB | Every shared layer counted ten times | | Actual host storage | 1700 MB | 700 MB base once, plus ten × 100 MB | | Marginal cost of the eleventh image | 100 MB | Only the layers the host lacks | The gap widens with the number of images and the size of the shared base — which is exactly the direction that makes capacity forecasts built on per-image sizes wrong by a large factor. ## Two different sizes for the same layer A second, independent source of confusion sits underneath the first. Each layer has: - a **compressed transfer size** — what moves across the network when a host fetches it; - an **expanded on-disk size** — what it occupies once unpacked and ready to be stacked. These can differ by several times for compressible content, and platforms differ over which one they report where. So "the image is 800 MB" may be a transfer figure, a disk figure, or a sum of layer figures in one of those two units. Before using any such number for capacity planning, establish which of the three it is. ## When sharing silently stops Sharing is per layer and it is all-or-nothing: two layers are the same layer only when their content is identical. The consequences are sharper than they first look. - Two images described as "built from the same base" share that base only if the base layers they actually reference are byte-identical. If the base was rebuilt in between so its contents differ at all, they are different layers, and the host now stores both. - A change to a lower layer forces every layer above it to be reproduced, so a small edit deep in the stack can end sharing for the whole upper part of the image. - Because a layer is the unit of sharing, a shared layer's hidden contents are also shared: a large object buried by a later layer is at least stored only once across all the images that inherit it. The practical rule is that a fleet's storage depends on how many **distinct** layers exist across the images it runs, not on how many images it runs. Estates that pin every workload to a small set of common base layers store a fraction of what estates with a base layer per team store, at identical per-image sizes. ## How to reason about the numbers 1. For **one** image, the reported size is the right number: it is what a host with nothing needs to obtain it. 2. For a **host or a fleet**, count distinct layers once and ignore per-image totals entirely. 3. For the cost of **adding** an image to a host that already runs related ones, count only the layers that host does not already hold — often a small fraction of the image's reported size. ## Answering it in an interview Say that a host stores content-identified layers once and that images are lists of references to them, so per-image sizes include shared layers and summing them double-counts. Then show the judgment: the number that matters for a host is distinct layers, the number that matters for a deployment is the layers that host lacks, and sharing quietly disappears the moment two supposedly identical base layers are not byte-identical.