DevOps Peach

Docker & Kubernetes · Docker Storage – Volumes, Bind Mounts and Storage Drivers · Lesson 4 of 4

Storage drivers

The storage driver stacks image layers and the writable layer on the host; overlay2 is the standard choice, and volumes bypass it.

Practice interactively →

What a storage driver does

The storage driver decides how image layers and the writable layer are stored and combined on the host, so each container sees a single filesystem. Docker has a pluggable architecture: several drivers, each with pros and cons; use the most stable and fastest one for the common case.

flowchart BT
  I1["Image layer 1"] --> I2["Image layer 2"]
  I2 --> W1["Writable layer: web-1"]
  I2 --> W2["Writable layer: web-2"]
  SD["Storage driver (overlay2)"] -.-> W1
  SD -.-> W2

Many containers share the image layers underneath; each container only has its own changes (copy-on-write).

Drivers today

Driver Notes
overlay2 The recommended Linux driver with the classic image store
overlayfs (containerd snapshotter) Shown by docker info with the containerd image store, the default for new installs since Docker Engine 29
btrfs, zfs When the host filesystem is btrfs/zfs
devicemapper Removed in Docker Engine 25; older material still mentions it

Configure it in /etc/docker/daemon.json:

{ "storage-driver": "overlay2" }

Changing the storage driver makes existing images and containers "disappear" from Docker (they stay on disk under the old driver), so only change it on a fresh host.

Volumes bypass the storage driver

The storage driver only manages images and writable layers. Data in volumes and bind mounts is written straight to the host filesystem, so it has no copy-on-write overhead.

Command Meaning
docker info --format '{{.Driver}}' Print the name of the storage driver in use
docker info The Storage Driver section plus much more

How overlay2 builds the view

overlay2 merges directories: the image layers become read-only lowerdirs, the container's changes go to an upperdir, a workdir is used internally, and the merged directory is what the container sees. docker inspect -f '{{json .GraphDriver.Data}}' web shows these paths. Deleting an image file inside a container creates a "whiteout" entry in the upper layer that hides the file below; the original layer is untouched.

Host requirements

overlay2 works on ext4, and on xfs only when it was formatted with ftype=1 (the default on modern systems). Running Docker on an unsupported backing filesystem leads to errors or silent fallbacks, so check docker info after installing on a new host.

The containerd image store

New installations use containerd to store images (the overlayfs snapshotter). It brings features that the classic store lacked: storing multi-platform images locally, keeping attestations such as SBOMs with the image, and sharing images with other containerd clients. The day-to-day docker commands stay the same.

Moving Docker's data

If /var/lib/docker sits on a small root disk, move it to a larger one with "data-root": "/data/docker" in daemon.json. Stop Docker, copy the old directory with rsync -aP, update the setting, and start Docker again.

Keeping the disk under control

Container logs live next to the storage driver's data and are the most common cause of a full disk. Set rotation for the default json-file driver in daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

The local log driver compresses and rotates by default. Combine this with regular docker system prune (for example from a cron job) and disk alerts on the Docker host.

Practice interactively →