为什么使用AUFS作为默认Docker存储后端而不是devicemapper？

Project Atomic对Docker的描述描述了AUF与其他存储后端选择（如devicemapper）之间的技术差异。不在上游Linux内核中。为什么选择AUFS作为默认存储后端（例如在Ubuntu的Docker中）？AUFS是否有一些技术特性使其成为比存储后端更好的选择，例如似乎由未修补的Linux内核支持的devicemapper？

AUFS只是系统/发行版上可用的默认存储后端。否则，devicemapper是默认值。例如，Ubuntu 14.04默认为devicemapper：

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
$ docker info | grep Storage
Storage Driver: devicemapper

---

这在过去发生了变化。在0.7.0之前，Docker依赖AUFS作为其唯一的存储驱动程序，这就是为什么它在早期版本的Ubuntu中是默认的。

我远不是文件系统方面的专家，但是Discussion的人，他们是。使用DeviceMapper可能会导致“痛苦的世界”

报纸上说：

aufs驱动程序是最古老的，但基于Linux内核补丁集，不太可能合并到主内核中。这些也会导致一些严重的内核崩溃

我在ubuntu 16.04上的Docker 17.06.2~ce-0~ ubuntu中遇到了这些内核崩溃，默认内核

---

我正在ext4文件系统上使用

overly2

；Docker现在工作正常。

有趣的是，Ubuntu 14.04也默认为devicemapper。然而，该链接说：“如果您的系统支持AUFS，它将继续使用AUFS驱动程序”。如果可用的话，AUFS会让Docker更喜欢它而不是devicemapper吗？只是如果系统在0.7之前对Docker有AUFS支持，他们仍然希望自己的映像正常工作。如果存储驱动程序更改，则映像将不兼容，从而破坏这些系统。通过设备映射器，我们的info aufs没有任何技术优势。我们在AWS上使用devicemapper（m3.medium实例，EBS磁盘安装到/var/lib/docker dir）时存在性能问题。使用btrfs/etx4文件系统和devicemapper，我们的构建时间大约为20分钟。使用btrfs文件系统和btrfs设备Apper，我们将构建时间缩短到12分钟。使用ext4文件系统和aufs设备apper大约需要6分钟。所以，至少AWS基础设施的性能水平存在差异，当然也存在性能差异。devicemapper速度慢得多，因为它作为块设备运行。但这个问题是关于为什么devicemapper是默认的，原因与性能无关，而是因为大多数发行版的内核中缺少AUFS支持。如果您的LVM卷没有精简配置（应该是这样），或者您出于某种原因根本不使用LVM，那么速度会慢很多。精简资源调配提供了Docker在性能方面所依赖的写时复制语义。我最近遇到了Docker退出代码159，这意味着某种文件大小限制已经超出。最后我发现这是由设备映射器引起的，所以我不得不重新安装docker并改为使用overlay驱动程序。这个信息已经过时了。默认的存储后端现在是

overlay2

，它现在在所有发行版上都可用，而且更可靠。