The right storage driver to use really depends on your use case, how much up-front work you’re willing to put into configuring it, how much risk you can afford to take, and how much work you’re willing to put into supervising it and ensuring that nothing wacky happens once implemented.
devicemapper historically has been full of headaches. It can be incredibly flaky and slow, and I don’t think the upstream maintainers really like maintaining it very much. I’d use it only if all of the other options were not possible for you.
By far the most “plug-and-play” solution today is
aufs, and this is largely why it is the default in many instances.
aufs gets a lot of attention from upstream and any issue you encounter is likely to be run into by someone else first, helping with debugging. However, its negatives include some show-stopping bugs related to permissions which mandate hacky workarounds if you run into them. It will also most likely never land in the kernel directly, and is not as performant as some of the other drivers.
The up-and-coming star is
overlay, which is directly in the Linux kernel (versions >=3.18 IIRC), but still has some issues with respect to its Docker integration. In particular, if you use
overlay, follow these tips. Actually, you’ll notice in the sidebar that most of the storage drivers have “Foo in Practice” sections that are worth looking over. There have been some known issues with inode exhaustion and other bugs, but
overlay is fast/minimal compared to AUFS and well-supported upstream, so this is actually a decent bet for the future.
If you are running a service where you can afford some occasional weirdness / bugs / downtime and also are willing to run
overlay in all of the lower environments, I’d say it should be top of your list for investigating.
btrfs seemed quite promising initially but has had some stability issues (I’ve heard horror stories about having to periodically blow away
zfs is fairly new in terms of integration with Docker, and has a reputation as “Not Ready For Production” on Linux, but would definitely be worth a look at, and has some pretty desirable characteristics, although I’m not sure if they come into play for using it as a Docker storage driver.
By the way, most of these are available to play with using boot2docker, so if you’re using Docker Machine, you can create using
--engine-storage-driver flag to get a particular one on the created VM (or just edit
/var/lib/boot2docker/profile directly and run
sudo /etc/init.d/docker restart). Have a play!
Hope this helps,