Docker Filesystem and the Power of Copy-on-Write (CoW)

Published: (December 7, 2025 at 10:03 PM EST)
2 min read
Source: Dev.to

Source: Dev.to

Cover image for Docker Filesystem and the Power of Copy-on-Write (CoW)

The Container’s Filesystem Structure

A running container’s filesystem consists of two primary parts, layered on top of each other using a union filesystem (e.g., Overlay2).

Read‑Only Image Layers (Base)

  • Contain the operating system base, application binaries, and dependencies.
  • Multiple containers derived from the same image share these immutable layers.

Read‑Write Container Layer (Top)

  • A thin, final layer unique to the running container.
  • All data created, deleted, or modified while the container runs is written only to this layer, making it ephemeral.

The Copy‑on‑Write (CoW) Principle

When a container tries to modify a file that exists in a read‑only layer, Docker never alters the shared base layers. Instead, it follows the CoW process:

ActionCoW Principle Effect
Reading a FileThe container reads the file directly from the shared, read‑only layer (fast).
Modifying or Deleting a FileDocker copies the file from its original read‑only layer into the top read‑write layer, then modifies the copy. The original remains untouched for other containers.

Why CoW is Essential

  • Disk Efficiency – Base layers are shared, avoiding duplicate storage of OS files and libraries.
  • Speed and Immutability – Reads are instantaneous; the original image stays immutable, guaranteeing a clean start for every container.
  • Fast Boot Times – Only the thin writable layer is created on start‑up, not a full copy of the image filesystem.

Understanding Ephemeral Data

Changes written to the top writable layer are ephemeral—they exist only as long as the container does. Removing a container destroys this layer:

docker rm 

The writable layer and all its data are gone forever.

Because containers are designed to be stateless and disposable, any data that must persist across restarts or deletions (e.g., database contents, logs) should be stored in Docker volumes.

What’s Next?

We’ve covered the theoretical foundations: the why (Post 1), the what (Images and Containers), the how (Architecture and Runtime), and now the efficiency (Filesystem and CoW). Stay tuned for a dedicated post on data persistence with Docker volumes.

Back to Blog

Related posts

Read more »