可插拔的存储驱动架构
Docker的存储驱动架构是可插拔的，可以让你很方便的将适合你环境和用例的存储驱动“插进”Docker。每个Docker存储驱动都建立在一种Linux文件系统或者卷管理系统之上，也可以很自由地按照其自己的方法去实现镜像层和容器层的管理。也就是说一些存储驱动在不同的场景下会比其他的驱动性能更好。
一旦你决定了哪种驱动最合适，你就可以Docker daemon启动之前设置驱动到Docker中，这样你就可以在该存储驱动上运行Docker daemon了，所有新容器都会使用这个驱动来创建了。下图显示了支持的驱动技术和它们对应的Docker存储驱动名称。
| Technology | Storage driver name |
|---|---|
| OverlayFS | overlay / overlay2 |
| AUFS | aufs |
| Btrfs | btrfs |
| Device Mapper | devicemapper |
| VFS | vfs |
| ZFS | zfs |
可以通过docker info命令来查看当前daemon使用着哪种存储驱动。
$ docker infoContainers: 0 Running: 0 Paused: 0 Stopped: 0Images: 1Server Version: 1.12.6Storage Driver: overlay2 Backing Filesystem: extfs ... output truncated ...
上面的输出表示，Docker daemon使用overlay2作为存储驱动，而其Backing Filesystem是extfs。也就是说，在我的环境中，overlay2存储驱动是在ext文件系统上操作的。后端文件系统指的是创建了Docker host的本地存储区域/var/lib/docker的文件系统。
存储驱动，可以运行在某种后端文件系统上，但也有些不支持的后端文件系统，它们之间的对应关系如下表：
| Storage driver | 后端文件系统 | 不支持的后端文件系统 |
|---|---|---|
| overlay | ext4 xfs | btrfs aufs overlay zfs eCryptfs |
| overlay2 | ext4 xfs | btrfs aufs overlay zfs eCryptfs |
| aufs | ext4 xfs | btrfs aufs eCryptfs |
| btrfs | btrfs only | N/A |
| devicemapper | direct-lvm | N/A |
| vfs | debugging only | N/A |
| zfs | zfs only | N/A |
想要设置存储驱动，可以在dockerd启动的时候加入--storage-driver=
$ dockerd --storage-driver=devicemapper & $ docker infoContainers: 0Images: 0Storage Driver: devicemapper Pool Name: docker-252:0-147544-pool Pool Blocksize: 65.54 kB Backing Filesystem: extfs Data file: /dev/loop0 Metadata file: /dev/loop1 Data Space Used: 1.821 GB Data Space Total: 107.4 GB Data Space Available: 3.174 GB Metadata Space Used: 1.479 MB Metadata Space Total: 2.147 GB Metadata Space Available: 2.146 GB Thin Pool Minimum Free Space: 10.74 GB Udev Sync Supported: true Deferred Removal Enabled: false Data loop file: /var/lib/docker/devicemapper/devicemapper/data Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata Library Version: 1.02.90 (2014-09-01) Execution Driver: native-0.2<output truncated>
存储驱动的选择会影响你容器应用的性能，所以很有必要理解存储驱动之间的区别和优缺点，然后才能选择合适的驱动。
共享存储系统和存储驱动
很多企业都从共享文件系统（如SAN和NAS）中获取存储资源。通常情况下，这都能带来更好的性能和更高可用性，还有如超配、副本删除、压缩等高级特性。
Docker存储驱动和数据卷都可以运行在这些共享存储系统提供的存储上，这使得Docker可以利用这些系统提供的优越性能和可用性。
使用哪种存储驱动呢？
很多方面都会影响存储驱动的选择，不过有两点必须记住：
没有哪种驱动适合所有的用户场景；
存储驱动一直都在提升和改进；
此外，下面的内容，也可以提供一些指导意见。
稳定性
为了Docker环境更加稳定，你应该考虑一下一些建议：
使用你OS发行版默认的存储驱动。安装Docker时，它会根据你的系统选择默认的存储驱动，稳定性是它选择的一个主要方面。
遵守CS Engine compatibility matrix指定的配置。CS Engine是Docker Engine的商业化版本，它代码基于开源的Engine。不过它有一套限制的支持配置，而这个支持的配置使用最稳定成熟的存储驱动。
经验和专业技能
选择你和你的团队都有经验的一种存储。比如，你使用RHEL系列的OS，你可能对LVM和Device Mapper很有经验，因此，你应该使用devicemapper存储驱动。
如果你对Docker提供的存储驱动都没有经验，并且你希望使用简单可用的稳定的Docker环境，那么你可以考虑使用你发行版默认的Docker存储驱动。
未来
很多人认为OverlayFS是Docker存储驱动的未来。然而，它还不够成熟，并且和aufs、devicemapper相比暂时还不够稳定。因此，使用OverlayFS时应该注意。
下图列出了所有驱动，并列出了它们的优缺点。如果要选择存储驱动，那么可以参考下面提到的内容。
Overlay vs Overlay2
OverlayFS有两种存储驱动，它们使用了相同的OverlayFS技术，但却有着不同的实现，在磁盘使用上也并不互相兼容。因为不兼容，两者之间的切换必须重新创建所有的镜像。overlay驱动是最原始的OverlayFS实现，并且，在Docker1.11之前是仅有的OverlayFS驱动选择。overlay驱动在inode消耗方面有着较明显的限制，并且会损耗一定的性能。overlay2驱动解决了这种限制，不过只能在Linux kernel 4.0以上使用它。
