We've discussed how containers are fast because they share the host OS kernel and use Namespaces and cgroups for isolation. But what about disk space and file operations? The secret here lies in Docker's efficient Filesystem and the Copy-on-Write (CoW) strategy.
1. The Container's Filesystem Structure
As we touched on, a running container's filesystem is composed of two primary parts, layered on top of each other using a Union File System (like Overlay2):
The Read-Only Image Layers (Base): These layers form the foundation of the container. They contain everything from the operating system base to the application binaries and dependencies. Multiple containers derived from the same image share these same read-only layers. This is the shared, immutable part.
The Read-Write Container Layer (Top): This thin, final layer is unique to the running container. Any data created, deleted, or modified while the container is running is written only to this top layer. This is the unique, ephemeral part.
2. The Copy-on-Write (CoW) Principle
The magic happens when a running container tries to modify a file that exists in one of the read-only image layers below it.
The Copy-on-Write (CoW) principle ensures that the shared base layers are never directly altered. It works like this:
| Action | CoW Principle Effect |
|---|---|
| Reading a File | The container reads the file directly from the shared, read-only layer (very fast and efficient). |
| Modifying or Deleting a File | Docker copies the file from its original read-only layer into the top read-write layer. The container then modifies this new copy. The original file in the base layer remains untouched for other containers to use. |
Why CoW is Essential:
- Disk Efficiency: Since all containers share the base layers, you don't waste disk space by storing multiple copies of the same OS files or libraries.
- Speed and Immutability: File reads are instantaneous (no copying needed). Furthermore, the original image is preserved (it's immutable), guaranteeing that every new container starts from a clean, known state.
- Fast Boot Times: Containers start quickly because they only need to create the thin, empty writable layer on top, not duplicate the entire image filesystem.
3. Understanding Ephemeral Data
Because changes are written to the top, thin, writable layer, this data is ephemeral.
Ephemeral means it exists only as long as the container does. If you run:
docker rm <container_name>
...the writable layer is destroyed, and all the data written to it is gone forever.
This is a key architectural design point: containers are designed to be stateless and disposable. For data that must persist across container restarts or deletions (like a database's contents or application logs), you must use Docker Volumes, which we will cover in a dedicated post on data persistence.
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).
Top comments (0)