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/docker is located)

Operating system, distribution, and Docker edition

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.

Backing filesystem (where /var/lib/docker is located)

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.

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.