EN
Back to the archive

The encyclopedia · Engineering & Operations · Technical decision · 2014–2015

Docker image layers share storage until a container writes, then copy

OverlayFS lets many containers share one read-only image and, thanks to copy-on-write, only copies a file when a container actually modifies it.

Docker / OverlayFS

the move

Running many containers from the same base image naively stores the whole image once per container, which is wasteful for frameworks and servers that share an identical large base.

OverlayFS solves it by layering. The base image is kept read-only as the lower layer; each container adds a small writable upper layer. Reads go to the lower layer, and when a container modifies a file, the driver copies the affected data up and writes there.

Because of copy-on-write, the shared base stays shared until an actual write forces a copy, so the storage cost is proportional to what each container changes rather than to the full image size, and start-up stays cheap on the same shared blocks.

why it works

  • A single shared read-only base is reused across many containers.
  • Copy-on-write means only modified data is duplicated.
  • Pull and start-up stay cheap because most layers are identical and shared.
the payoffDuplicate a file only when a container really changes itclever

what transfers

If many processes use the same unchanged resource, share it by default and pay to copy only at the moment of modification; that turns a per-process cost into a per-change cost.

what came after

OverlayFS became a default storage driver for Docker, and copy-on-write layering became the basis of how containerised workloads move and store images in production.

references

spotted an error? The archive wants to know.

same kind of clever