A large asset bundle is added in one layer and deleted in a later one — why doesn't the image shrink?

## What a layer actually records A layer is not a snapshot of the whole filesystem. It is a record of the **changes** made at one step: the files created or overwritten at that step, and the paths marked as gone. Once a layer is finished it is immutable — nothing produced afterwards can modify its contents, because later steps are expressed as more layers on top rather than as edits underneath. That immutability is what makes the format work. A layer that never changes can be stored once on a host and reused by every image that references it, and a host that already holds a layer never has to receive it again. The price is the behaviour in this question: **an image is append-only, so nothing added later can take anything away.** ## Why the removal frees nothing When a later step removes a path, the builder cannot delete the file from the earlier layer. What it can do is write a **deletion marker** into the new layer — a record meaning "from this layer upward, this path is absent". At run time the union filesystem resolves the path top-down, meets the marker first, and reports the file as missing. The process inside the container is satisfied: the file is gone. Everything else is unchanged: - The earlier layer still holds the file, byte for byte. - The image's layer list still includes that earlier layer, so the bytes still belong to the image. - Any host fetching the image receives that layer in full, because the layer is the unit of transfer and it cannot be partially sent. - On disk, the layer expands to its full contents, even though nothing can read the file through the merged view. - Anything that inspects the layers individually rather than through the merged view still finds the file exactly where it was written. The marker itself is tiny, so the net effect of "deleting" a large bundle is that the image gets *very slightly larger*. ## Worked numbers Take a report renderer service whose image carries a bundle of large template and font assets used only while preparing the image. | Layer | What it records | Stored size | |---|---|---| | 1 | Adds the template and font asset bundle under `/opt/report/assets` | 420 MB | | 2 | Adds the renderer executable under `/opt/report/bin` | 6 MB | | 3 | Deletion marker for `/opt/report/assets` | ~0 MB | The merged view contains 6 MB of files. The image stores and transfers 420 + 6 + 0 ≈ **426 MB**. Someone reading only the running container's filesystem sees 6 MB and concludes the image is small; someone watching a host fetch it sees 426 MB move. Both numbers are correct and they are measuring different things — which is precisely the confusion this question exists to expose. ## What actually removes the bytes There are only two mechanisms, and both operate at the moment the layer is produced: 1. **Add and remove inside the same layer.** If one build step creates the bundle, uses it and deletes it, the layer's recorded change is the *net* result — and the net result does not include the bundle. Nothing was ever committed, so there is nothing to hide. 2. **Never put it in the image.** Produce the artifact somewhere that is not part of the shipped layer stack, or fetch what is needed at run time, so no layer of the final image ever holds the bytes. What does **not** work, in any platform: deleting the path in a later step, overwriting it with something smaller, moving it to another path, or compressing it after the fact. Every one of those adds a layer and leaves the original where it is. ## How to read an image's size after this Two numbers describe every image and they are not the same: - The **compressed transfer size** — what moves over the network, layer by layer, including layers whose contents are entirely shadowed or marked deleted. - The **expanded on-disk size** — what the layers occupy once unpacked on a host, again including the hidden contents. Neither is the size of the merged view, and the merged view is the only one of the three a running container can show you. When an image is mysteriously several times larger than the files it appears to contain, a large object added and later removed is the single most common cause. ## Answering it in an interview Name the mechanism, the consequence and the fix, in that order: layers are immutable and append-only, so a later removal records a marker instead of erasing anything; the bytes therefore remain in the image, are transferred to every host, and still count toward its size; and the only repair is to stop the bytes entering a committed layer at all, by doing the add and the remove within one layer or by never placing the artifact in the image.