How does the Overlay2 Storage Driver and Copy-on-Write (CoW) filesystem operate?
❓ Interview Prompt: Explain OverlayFS lower/upper/merged directories, Copy-on-Write semantics, and how container writable layers work on top of read-only image layers.
Docker's default storage driver (overlay2) uses the Linux OverlayFS kernel module to implement the layered image filesystem:
OverlayFS Directory Structure:
docker rm).Copy-on-Write (CoW) Semantics:
When a process inside the container reads a file that exists in a lower layer, it reads directly from the lower layer — no copy needed.
When a process writes to a file from a lower layer, OverlayFS:
Performance Implication:
The first write to a large file triggers a full copy to the upper layer (copy-up) — this can cause latency spikes for write-heavy workloads. Solution: use Docker Volumes for I/O-intensive paths.
Code Implementation Example
# Inspect the overlay2 layer directories for a container
CONTAINER_ID=$(docker inspect myapp --format '{{.Id}}')
docker inspect myapp --format '{{.GraphDriver.Data}}'
# {
# "LowerDir": "/var/lib/docker/overlay2/abc123/diff:...",
# "MergedDir": "/var/lib/docker/overlay2/xyz789/merged",
# "UpperDir": "/var/lib/docker/overlay2/xyz789/diff",
# "WorkDir": "/var/lib/docker/overlay2/xyz789/work"
# }
# See the unified merged view (what container sees)
ls /var/lib/docker/overlay2/xyz789/merged/
# Demonstrate CoW: writing to a file copies it to UpperDir
docker exec myapp sh -c "echo 'modified' > /etc/hosts"
ls /var/lib/docker/overlay2/xyz789/diff/etc/
# hosts ← copy-up occurred, modified version is in UpperDirOverlayFS stacks read-only image layers (lowerdir) with a per-container writable layer (upperdir). First write triggers copy-up — use Volumes for high-I/O paths to avoid CoW overhead.