Lesson 10 of 30

Storage Drivers & the Union Filesystem

Q: Explain what actually happens, mechanically, when a running container modifies a file that already exists in the image it was built from.

A strong answer covers: States that image layers are read-only and never change once built; Names copy-on-write specifically: the file is copied up into the container's own writable layer before the modification is applied there; Explains why this makes the original image, and every other container built from it, unaffected by the change; Connects this to why a container is safe to delete — the writable layer is the only thing that changed, and discarding it discards nothing shared.

Layer caching only makes sense once you know what a layer actually IS — a union filesystem is the mechanism that stacks a dozen read-only diffs into one filesystem a running container can read and write like a normal disk.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A running container reads a file that exists only in a read-only image layer three levels down. What does the union filesystem do?

It serves the file directly from that lower layer, with no copyingIt copies the file into the writable container layer first, then reads it from thereIt fails, since only the writable layer is directly readable by the running containerIt merges that layer's contents into every other layer for future reads

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Storage Drivers & the Union Filesystem

What interviewers actually ask about this, and what a strong answer has to cover.

Explain what actually happens, mechanically, when a running container modifies a file that already exists in the image it was built from.

A strong answer covers

States that image layers are read-only and never change once built
Names copy-on-write specifically: the file is copied up into the container's own writable layer before the modification is applied there
Explains why this makes the original image, and every other container built from it, unaffected by the change
Connects this to why a container is safe to delete — the writable layer is the only thing that changed, and discarding it discards nothing shared

Likely follow-ups

If a Dockerfile deletes a large file in a later layer than the one that created it, why doesn't the final image get smaller? What's actually still stored?
Why would you reach for a volume instead of just letting the container write into its own writable layer, for something like a database's data directory?

Practice these with the AI interviewer →

The plain-language idea

The Dockerfile-layers lesson treated "every instruction produces a layer, and layers get cached" as a given. This lesson explains the mechanism underneath that fact: a union filesystem (Docker's default implementation is overlay2) is how Docker takes a stack of independent, read-only layer diffs and presents them to a container as one single, ordinary-looking filesystem.

Two rules explain the whole thing:

Every image layer is read-only, permanently. Once built, a layer's contents never change — that's what makes it safely shareable and cacheable across every container built from that image.
A running container gets exactly one additional layer that IS writable — the container layer, sitting on top of every read-only image layer. Anything the container creates, modifies, or deletes at runtime happens only in this one layer.

Reads fall through the stack top to bottom: asking for a file that only exists in a lower read-only layer works transparently, because the union filesystem presents all layers merged into one view.

See it in a real thing: reading vs. writing the same file

container layer (writable)         <- empty until something changes
──────────────────────────────
layer 3: RUN pnpm build (readonly)
layer 2: RUN pnpm install (readonly)
layer 1: COPY package.json (readonly)
layer 0: FROM node:20-alpine (readonly)

Union filesystem: reading vs. writing the same fileStep 1 of 4

The layer stack: three read-only image layers, plus one empty writable container layer on top.

Reading /app/package.json from inside the running container falls straight through the empty writable layer to layer 1, where it actually lives — no copying happens. But the moment the container process writes to that same file, the union filesystem performs copy-on-write: it copies the file up into the writable container layer first, then applies the write there. The original copy in layer 1 is untouched — it's read-only, permanently — and every other container built from the same image still sees the original, unmodified version.

What people usually miss

Watch out

Copy-on-write has a real performance cost for large-file, write-heavy workloads. Copying a multi-gigabyte file up into the writable layer before a small write can touch it is a genuine reason a database's data directory belongs in a volume, not the container's writable layer — volumes bypass the union filesystem entirely.
Deleting a file in a running container doesn't remove it from the lower read-only layer. The union filesystem records a "whiteout" marker in the writable layer that hides the file from view — the file's bytes are still sitting in the read-only layer underneath, which is part of why deleting a large file late in a Dockerfile doesn't shrink the resulting image.
The writable container layer is why two containers from the same image can end up with different files, even though they share every read-only layer underneath — each container's writes only ever land in its own private writable layer, never anyone else's.
docker diff shows exactly this writable layer — it lists every file a running container has added, changed, or deleted relative to its image, which is the concrete, inspectable version of the abstract "copy-on-write" story above.

Why this matters in interviews

"What actually happens when a running container writes to a file?" tests whether layer caching is understood as a mechanism (union filesystem, read-only layers, copy-on-write) or just memorized as "Docker caches layers, it's faster." The strong answer names copy-on-write specifically and explains why it makes containers both fast to start and safe to discard.