By default, Docker will use the AUFS storage backend if available, and then fall back to devicemapper on loopback.<p>RHEL, CentOS, and Fedora do not ship the AUFS kernel module because it is not part of the mainline Linux kernel and is unlikely to be included in future, and these distros have an "upstream first, no out-of-tree bits" policy. Instead, they recommend using devicemapper on LVM [1][2].<p>The same advice is provided in the official Docker documentation [3]:<p>> Docker hosts running the devicemapper storage driver default to a configuration mode known as loop-lvm... The mode is designed to work out-of-the-box with no additional configuration. However, production deployments should not run under loop-lvm mode... The preferred configuration for production deployments is direct lvm.<p>You might consider using CentOS Atomic Host, which comes preconfigured with LVM thin pools.<p>OverlayFS is also an alternative, but it can be problematic. It only implements a subset of the POSIX standard [4], which can cause some programs to fail.<p>[1] <a href="http://www.projectatomic.io/blog/2015/06/notes-on-fedora-centos-and-docker-storage-drivers/" rel="nofollow">http://www.projectatomic.io/blog/2015/06/notes-on-fedora-cen...</a>
[2] <a href="https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/getting-started-with-containers/#managing_storage_with_docker_formatted_containers" rel="nofollow">https://access.redhat.com/documentation/en/red-hat-enterpris...</a>
[3] <a href="https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/" rel="nofollow">https://docs.docker.com/engine/userguide/storagedriver/devic...</a>
[4] <a href="https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/" rel="nofollow">https://docs.docker.com/engine/userguide/storagedriver/overl...</a>