Docker Storage Drivers
Docker storage drivers control how images and containers are stored and managed on disk. Understanding overlay2, aufs, devicemapper, btrfs, and zfs helps you optimize performance, storage efficiency, and reliability for your container workloads.
Docker storage drivers (also called graph drivers) are pluggable components that manage how Docker stores image layers and container writable layers on disk. Each driver uses different technologies to implement copy-on-write (CoW) filesystems, which allow containers to share the same base image layers while having their own writable layer for changes.
The choice of storage driver affects performance, disk space usage, and compatibility with different filesystems. The default driver on most modern Linux distributions is overlay2, which is stable, performant, and recommended for most workloads.
Docker Image (Read-Only Layers)
┌─────────────────────────────┐
│ Layer 3: CMD │
│ Layer 2: COPY app │
│ Layer 1: FROM node:18 │
└─────────────────────────────┘
│ copy-on-write
↓
Container (Read-Write Layer)
┌─────────────────────────────┐
│ Container changes only │
└─────────────────────────────┘
docker info | grep "Storage Driver". Most modern Linux systems use overlay2 by default.
| Driver | Filesystem Support | Performance | Status | Use Case |
|---|---|---|---|---|
| overlay2 | ext4, xfs (with d_type) | Excellent | Stable, default | Most workloads |
| aufs | Legacy Linux kernels | Good | Deprecated | Legacy systems |
| devicemapper | Direct-lvm | Fair (thin provisioning) | Deprecated | CentOS/RHEL 7 |
| btrfs | btrfs | Good (snapshots) | Optional | Btrfs filesystems |
| zfs | zfs | Good (clones) | Optional | ZFS filesystems |
| vfs | Any | Poor (no CoW) | Testing only | Testing |
Overlay2 is the current default storage driver for Docker on Linux. It uses the Linux kernel's overlay filesystem to efficiently manage image layers with copy-on-write. Overlay2 requires a filesystem that supports d_type (directory type information), which is true for ext4 and xfs when properly formatted.
Benefits of overlay2: excellent performance (low overhead), efficient memory usage (fewer inodes), good layer sharing, and stable in production. Overlay2 supports up to 128 lower overlay layers (practically enough for almost all images). It's the recommended driver for all modern Linux distributions.
# Check if your filesystem supports d_type
xfs_info /var/lib/docker | grep ftype
# ftype=1 means d_type is supported
# Check current storage driver
docker info | grep -A 5 "Storage Driver"
# Typical overlay2 configuration in daemon.json
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
# Restart Docker after configuration
sudo systemctl restart docker
AUFS (Another Union Filesystem) was Docker's original storage driver. It was stable and well-tested but never merged into the mainline Linux kernel. AUFS is still available on some distributions (like Ubuntu), but it is considered deprecated in favor of overlay2.
AUFS supports unlimited layers (practically) and has good performance. However, because AUFS is not in the mainline kernel, it requires kernel patches. Most distributions have moved to overlay2, and AUFS should not be used for new deployments.
# Check if AUFS is available
lsmod | grep aufs
# Install aufs-tools (Ubuntu)
sudo apt-get install aufs-tools
# Note: AUFS is deprecated. Use overlay2 instead.
Device Mapper was the default driver on CentOS and RHEL 7. It uses thin provisioning and snapshots to manage layers. Device Mapper has two modes: loopback (not recommended for production) and direct-lvm (recommended).
Device Mapper has significant limitations: it can be slow, has a 128-layer limit, and requires careful configuration. The direct-lvm mode provides better performance but adds operational complexity. With the availability of overlay2 on CentOS 8+ and RHEL 8+, Device Mapper is now deprecated.
# Check if using device-mapper
docker info | grep "Storage Driver"
# Storage Driver: devicemapper
# Configure direct-lvm (not recommended for new setups)
# See Docker documentation for detailed setup
# Migration to overlay2 (on CentOS 8+)
# Ensure filesystem supports d_type
# Change storage driver in /etc/docker/daemon.json
Btrfs is a copy-on-write filesystem that supports subvolumes and snapshots. The btrfs storage driver leverages these features to implement efficient container layering. It's an excellent choice if you're already using btrfs for your Docker storage.
Benefits of btrfs: efficient snapshots, native compression, RAID support, and built-in integrity checking. However, btrfs requires more complex setup than ext4/xfs and the driver is less tested than overlay2. Use btrfs if you have specific needs for its advanced features.
# Create btrfs filesystem (requires spare device)
sudo mkfs.btrfs /dev/sdb
sudo mount /dev/sdb /var/lib/docker
# Configure Docker to use btrfs
{
"storage-driver": "btrfs"
}
# Check btrfs usage
sudo btrfs filesystem show
sudo btrfs subvolume list /var/lib/docker
ZFS (Zettabyte File System) is an advanced filesystem with excellent snapshot, clone, and compression features. The zfs storage driver uses ZFS datasets and clones to implement container layering. ZFS is a popular choice for large-scale container deployments, especially in enterprise environments.
Benefits of ZFS: high reliability, native compression, deduplication, snapshots, and RAID support. ZFS is more complex to set up than ext4/xfs but offers enterprise-grade features. The zfs storage driver is stable and used in production by many organizations.
# Create ZFS pool (requires spare device)
sudo zpool create -f dockerpool /dev/sdb
# Configure Docker to use ZFS
{
"storage-driver": "zfs"
}
# Check ZFS usage
zpool list
zfs list
# Set ZFS dataset for Docker
sudo zfs create dockerpool/docker
sudo zfs set mountpoint=/var/lib/docker dockerpool/docker
The vfs (Virtual File System) driver does NOT implement copy-on-write. Each layer is a complete copy of the parent layer, leading to enormous disk usage. This driver exists primarily for testing and for filesystems that don't support any CoW drivers.
Do not use vfs for production. A single image can consume gigabytes of disk space because each layer duplicates all parent layers. VFS is only useful for testing scenarios where you want to test layer behavior without CoW.
# Enable vfs (NOT for production)
{
"storage-driver": "vfs"
}
# Check disk usage - each layer is a full copy
du -sh /var/lib/docker/vfs/
- Use overlay2 on modern Linux distributions - Default on Ubuntu 20.04+, Debian 10+, CentOS 8+, Fedora. This is the best choice for most workloads.
- Use btrfs if you're already using btrfs - Takes advantage of native btrfs features like compression and snapshots.
- Use zfs for enterprise environments - ZFS offers excellent reliability, snapshots, and features like deduplication.
- Avoid devicemapper and aufs - Both are deprecated. Migrate to overlay2 if possible.
- Never use vfs in production - Disk usage will be enormous.
# Check current storage driver
docker info | grep "Storage Driver"
# Show more details about storage
docker system df
docker system df -v
# Show layer information for an image
docker history nginx:alpine
# Configure storage driver in daemon.json
sudo nano /etc/docker/daemon.json
# Example configuration for overlay2
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.size=20G"
]
}
# Restart Docker after changes
sudo systemctl restart docker
# Verify configuration
docker info | grep -A 10 "Storage Driver"
Storage driver performance affects container start time, image build speed, and I/O operations:
- overlay2 - Best overall performance. Low overhead, efficient caching, fast container start.
- aufs - Comparable to overlay2 but deprecated.
- devicemapper (direct-lvm) - Acceptable for read-heavy workloads, slower for write-heavy.
- btrfs/zfs - Good performance with additional features; snapshot operations are very fast.
- Bind mounts - For high-performance I/O (databases), consider using bind mounts on a high-performance filesystem directly, bypassing the storage driver for that path.
# Check disk space (common issue)
df -h /var/lib/docker
# Clean up unused data
docker system prune -a
docker volume prune
docker builder prune
# Check for overlay2 issues
sudo dmesg | grep overlay
sudo cat /var/log/docker.log | grep -i overlay
# Reset Docker storage (DANGER: removes all data)
sudo systemctl stop docker
sudo rm -rf /var/lib/docker
sudo systemctl start docker
# Check if overlay2 is supported on your kernel
grep overlay /proc/filesystems
For most users, overlay2 is the right choice. It's stable, performant, and the default on modern Linux systems. Only change drivers if you have specific requirements for btrfs or zfs features.