19.3.4.2 Info Storage Driver

The storage driver information in docker info describes how the Docker daemon manages the layered filesystem used by images and containers. Every Docker image consists of read-only layers stacked on top of each other, and every running container adds a writable layer on top of the image layers. The storage driver is the component responsible for creating, reading, and writing these layers efficiently on the host filesystem.

Storage Driver in docker info Output

docker info

Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Using metacopy: false
 Native Overlay Diff: true
 userxattr: false

Storage Driver Name

The first line identifies which storage driver the daemon is using:

Storage Driver: overlay2

overlay2

overlay2 is the default and recommended storage driver for Docker on modern Linux systems. It uses the kernel's OverlayFS feature to create a union filesystem by stacking image layers. Each layer is stored as a directory on the host, and overlayfs presents them as a single unified filesystem view inside the container.

The overlay2 driver requires:

• Linux kernel 4.0 or newer (5.x+ for full feature support).
• A backing filesystem that supports d_type (ext4, xfs with ftype=1).
• Not all filesystems support overlay2 (for example, NFS and overlay-on-overlay configurations are unsupported).

Other Storage Drivers

• devicemapper: Uses Linux's Device Mapper framework with thin provisioning. Used in older environments before overlay2 matured. Performance is inferior to overlay2 in most benchmarks. Deprecated in favor of overlay2.
• btrfs: Uses the Btrfs copy-on-write filesystem for layer management. Requires the Docker root directory to be on a Btrfs filesystem.
• zfs: Uses the ZFS filesystem's snapshotting capabilities. Requires a ZFS storage pool.
• vfs: A simple, inefficient driver that creates a full copy of each layer. Used only for testing and on filesystems that support no other driver.
• aufs: The original Docker storage driver on Ubuntu-based systems. Requires an out-of-tree kernel module. Deprecated.

Backing Filesystem

Backing Filesystem: extfs

The filesystem type of the partition where the Docker root directory (/var/lib/docker) resides. The value extfs indicates ext4. Common values:

• extfs: ext2, ext3, or ext4 — the most common Linux filesystems.
• xfs: XFS filesystem, common on RHEL/CentOS systems. Requires ftype=1 for overlay2 support.
• btrfs: Btrfs filesystem.
• zfs: ZFS filesystem.
• tmpfs: A memory-backed filesystem; impractical for production.

The storage driver must be compatible with the backing filesystem. overlay2 works on ext4 and XFS (with ftype=1), but not on NFS or certain network filesystems.

Supports d_type

Supports d_type: true

d_type is the directory entry type field in the Linux filesystem. It allows the filesystem to return file type information (regular file, directory, symlink, etc.) without opening each entry. The overlay2 storage driver requires d_type support.

On XFS filesystems, d_type support depends on how the filesystem was formatted. XFS formatted without ftype=1 does not support d_type and cannot use overlay2. The Docker daemon detects this and falls back to a less efficient method or refuses to start with overlay2.

If Supports d_type: false appears, the storage driver may work in a limited mode or the daemon may have issued a warning about this configuration.

Using metacopy

Using metacopy: false

Metacopy is a Linux kernel feature (added in kernel 5.6) that optimizes the overlay2 copy-on-write behavior. Normally, when a container modifies file metadata (such as permissions or timestamps) without changing the file's content, the entire file is copied to the upper layer. With metacopy enabled, only the metadata is copied, improving performance and reducing disk usage for metadata-only modifications.

false means either the kernel does not support metacopy or it was not enabled in the Docker daemon configuration.

Native Overlay Diff

Native Overlay Diff: true

When true, Docker uses the kernel's native OverlayFS diff computation to determine what changed between layers. This is efficient because the kernel tracks the changes internally. When false, Docker uses a slower user-space comparison method to compute diffs.

false appears when:

• The underlying filesystem does not support native OverlayFS diff.
• The Docker daemon was started with the overlay2.override_kernel_check=true configuration option to bypass kernel version checks.

userxattr

userxattr: false

In rootless Docker mode (running Docker without root privileges), the daemon may use user-namespace extended attributes (userxattr) to store overlay layer metadata. false means this is a regular root-mode Docker installation. true indicates rootless mode is in use.

Checking and Changing the Storage Driver

To check the current storage driver:

docker info --format "{{.Driver}}"

The storage driver is configured in /etc/docker/daemon.json:

{
  "storage-driver": "overlay2"
}

Changing the storage driver requires restarting the Docker daemon and causes all existing images and containers to become inaccessible (they were stored using the previous driver's format). On a production host, changing the storage driver means re-pulling all images and recreating all containers.

Impact on Performance

The choice of storage driver significantly affects container I/O performance. overlay2 is the most performant driver for most workloads because it uses the kernel's efficient copy-on-write mechanism. However, for workloads that perform many small writes (databases, write-intensive applications), using a Docker volume (which bypasses the storage driver entirely and accesses the backing filesystem directly) is far more efficient than writing to the container's writable layer.