A Small Edit Can Copy a Whole Image File into a Container’s Writable Layer

Establish which storage implementation the offer uses

Docker’s documentation, checked October 21, 2026, covers classic overlay2 separately from the containerd image store’s overlayfs snapshotter and fuse-overlayfs. The example below follows the classic driver; its rule should not be transferred to those other implementations.

The image supplies read-only lower directories. Each container has a writable upper directory, and the application sees a merged view. For a regular file present at the same path in both, the upper version takes precedence. The merged view exposes the selected version; it is not another stored copy of every file.

The related container pull-size guide explains compressed blobs, archives and broad runtime accounting. Here the narrower question is what happens when an application changes a file already embedded in its image.

References: [D1][D2][K1]

Follow the file into the writable layer

Docker describes whole-file copy-up before changing a lower-only file’s data. That preserves the original image file while creating an upper file whose length can greatly exceed the edited region.

The Linux kernel’s OverlayFS reference also explains that opening for write access can trigger copy-up before any data is changed. Treat the first data edit as the case being evaluated here, rather than a guarantee that every earlier operation left the file solely in the lower layer.

Once the upper copy exists, subsequent writes operate on it. The distinction is between acquiring that copy and changing it later, not between large and small application edits.

References: [D1][K1]

Work two 1 KiB edits through one 64 MiB image file

Consider a fictional application with one ordinary image file whose logical length is exactly 64 MiB. Two containers, A and B, share the same retained lower image file and start without an upper copy of it. Each performs a successful in-place edit of 1 KiB, preserving the file’s length. Retain both resulting upper files. These are stipulated inputs, not a test result or a specification for a GPU application.

Here 1 MiB is 1,048,576 bytes and 1 KiB is 1,024 bytes. Before either edit, the counted population is the one 64 MiB lower file. After A’s edit, A has a 64 MiB upper file as well. After B’s independent first edit, B has its own 64 MiB upper file.

The edited regions total 1 + 1 = 2 KiB. The upper-file logical payload totals 64 + 64 = 128 MiB. Including the original lower file once gives 64 + 64 + 64 = 192 MiB across three file payloads. Each container still sees one 64 MiB file at that path; summing the two merged views would answer a different question.

Now stipulate another in-place 1 KiB edit by A, with its existing upper file retained and its length unchanged. The counted upper payload remains 128 MiB. That later edit does not introduce a second first-copy of A’s file. B’s copy is separate because B has a different writable layer.

The 192 MiB figure counts only these three logical file payloads. It excludes other image files, archives, metadata, logs and separately supplied data. It is neither a host-capacity requirement nor a measurement of allocated blocks, device writes or elapsed time.

References: [D1][D2][U1]

Separate reading, hiding and modifying the file

Reading a lower-only file does not by itself require a private upper data copy. In the fictional case, an additional container that only reads the original file would not add another 64 MiB upper payload to this accounting. This says nothing about memory caches or the host’s total resource use.

Deleting a lower-only file from a container’s view has a different meaning again. A whiteout in the upper layer hides that path while the lower image file remains. The disappearance of a pathname therefore does not prove reclamation of the original image data. This deletion case is separate from the two successful edits above.

These differences matter when an application reports that it used, changed or removed a file. Identify which operation occurred and where its resulting state lives before assigning a storage quantity to that report.

References: [D2][K1]

Compare the mutable file population behind the offer

A supplier statement that each worker changes only 1 KiB leaves the file population unresolved. For the fictional application, ask whether that edit falls inside the 64 MiB embedded file, whether the file already has an upper copy, and how many independent writable layers retain such a copy at the lifecycle stage being compared. Those answers distinguish a tiny edit from the state retained around it.

Compare two proposed application behaviors using the same image: one leaves the embedded file unchanged; the other performs the stipulated edits in A and B. The latter has 128 MiB more upper-file logical payload in this example, despite sharing the same original image. A compressed pull figure cannot resolve that difference. The related pull-size guide explains transfer and archive accounting.

Separately supplied application data needs its own population. Docker documents volumes as storage outside a container’s writable layer, with a lifecycle independent of that container. If the actual edited file is supplied through a volume, the embedded-file calculation above is not its storage model. Establish where that data is held, whether it is shared and what retained copies the proposal includes. Account for the supplied data independently; a separate data location does not erase an embedded original from a retained image.

For a real comparison, have the appointed platform and application owners reconcile file lengths, actual allocation and retained state for the named driver, backing storage and workload stage. The useful purchasing result is a substantiated storage requirement for that arrangement. A count of changed bytes, on its own, cannot supply it.

References: [D2][D3]

Connect selected equipment to a physical installation scope

If that separate assessment leads to server or storage equipment requiring physical installation, Leviathan’s rack-and-stack service covers agreed equipment mounting, IT cabling, labels and installation records. Use the related service and project-inquiry links with a nonconfidential equipment list, site, released rack positions and connection requirements. Runtime design, allocation and software configuration stay with the appointed platform team.

References: [L1]