Copy-on-Write

The upper layer in an overlayfs stack is the container's writable layer. Reads of unmodified files come from the lower (read-only) layers. Writes trigger copy-on-write:

container reads /etc/hostname:
  -> file from nginx layer (read-only)
  -> serve directly

container writes /etc/hostname = "mybox":
  -> COPY /etc/hostname from lower layer to upper layer
  -> WRITE the new content to upper copy
  -> serve upper from now on

The lower layers stay pristine. Stopping the container preserves the upper layer (Docker calls this the container layer); it's lost when the container is REMOVED (not just stopped).

Implications:

• Initial container start: instant (no copying)
• First write to an unmodified file: full file copy (can be slow for big files)
• Subsequent writes: regular file I/O on the upper

Limitations:

• The upper layer is per-container — N containers = N upper layers
• Heavy writes inside a container can fill /var/lib/docker if upper grows
• Best practice: write transient state to volumes (-v mounts) which bypass overlayfs

Volumes vs writable layer:

• Volumes: separate filesystem mounted in; persist across container removal
• Container layer: ephemeral, throw-away, slower for big writes

For images you'll publish: keep them small (multi-stage builds, scratch base, statically linked binaries). Each layer adds startup time and disk overhead.