Docker storage driver requirements and considerations
Docker images consist of a series of read-only layers, each representing an instruction in the image's Dockerfile. When Docker creates a container from an image, it creates a new writable layer (container layer) on top of the underlying image layers. The storage driver configured in Docker determines how your host system interacts with these layers.
Typical Docker setups will automatically configure the most appropriate storage driver for a given system. You can determine which storage driver is being used by running docker info on the host machine, which will return output similar to:
docker info
which outputs:
Containers: 0
Images: 0
Storage Driver: overlay
Backing Filesystem: extfs
...
In this example, Docker is using the overlay storage driver.
A storage driver sometimes needs to be explicitly configured for a given system, depending on the following:
- The host’s operating system, distribution, and Docker edition
- The backing filesystem (i.e. where
/var/lib/dockeris located)
overlay2 is the recommended storage driver whenever possible, but any of the below should work:
- Ubuntu:
aufs,devicemapper,overlay2(Ubuntu 14.04.4 or later, 16.04 or later), overlay, zfs, vfs - Debian:
aufs,devicemapper,overlay2(Debian Stretch), overlay, vfs - CentOS:
devicemapper,vfs,overlay2 (if xfs created with d_type=true) - RHEL:
devicemapper,vfs,overlay2 (if xfs created with d_type=true) - Fedora:
devicemapper,overlay2(Fedora 26 or later, experimental),overlay(experimental),vfs
Please contact Plotly support if you need help configuring a storage driver while using a Docker edition other than Docker CE.
Specific backing filesystems are required for some storage drivers:
Storage driver | Supported backing filesystems |
|---|---|
overlay, overlay2 | ext4, xfs |
aufs | ext4, xfs |
devicemapper | direct-lvm |
btrfs | btrfs |
zfs | zfs |
Additionally, some backing filesystems will require additional configuration depending on the host system’s OS and kernel version, as discussed in Further considerations and cautions.
Running the
devicemapper storage driver in loopback mode is highly unstable and not recommended for production systems. Instead, configure devicemapper in direct-lvm mode as described in Dash app manager boot failure. (Note that devicemapper is the default storage driver for Centos 7/RHEL 7 systems.)Occasionally, storage drivers may have additional prerequisites that could render them incompatible with your system or require additional system configuration. This includes kernel version requirements as well as filesystem formatting. For example, the xfs backing filesystem is supported for the
overlay storage driver, as long as d_type=true is set you can verify that with xfs_info /mount-point The 3rd column of the 6th line of the xfs_info output is the most interesting because it contains the parameter ftype which should be 1. When ftype is 0, d_type support is disabled. When it is 1, d_type support is enabled and you're safe to use the overlay(2) storage driver with Docker on an XFS filesystem.Example of Terminal output:
$ xfs_info /mount-point
meta-data=/mount-point isize=512 agcount=4, agsize=2620928 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=10483712, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1 <<--- This is the line you are looking for
log =internal bsize=4096 blocks=5119, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
See the Docker storage driver documentation for additional information on storage drivers and selection/configuration.