AUFS经过结合挂载的方式将多个层文件堆叠起来，构成一个一致的全体提供一致视图，当在读写层停止读写的时，先在本层查找文件能否存在，假设没有则一层一层的往下找。aufs的操作都是基于文件的，需求修正一个文件时无论大小都会将整个文件从只读层拷贝到读写层，因此假设需求修正的文件过大，会招致容器执行速度变慢，docker官方给出的建议是经过挂载的方式将大文件挂载出去而不是放在镜像层中。

OverlayFS

OverlayFS可以以为是AUFS的晋级版本，容器运转时镜像层的文件是经过硬链接的方式组成一个下层目录，而容器层则是任务在下层目录，下层目录是可读写的，下层目录是只读的，由于少量的采用了硬链接的方式，招致OverlayFS会能够会出现inode耗尽的状况，后续Overlay2对这一成绩停止了优化，且功用上失掉了很大的提升，不过Overlay2也有和AUFS有异样的弊端——对大文件的操作速度比较慢。

DeviceMapper

DeviceMapper和前两种Storage-driver在完成上存在很大的差异。首先DeviceMapper的每一层保存的是上一层的快照，其次DeviceMapper对数据的操作不再是基于文件的而是基于数据块的。

下图是devicemapper在容器层读取文件的进程：

首先在容器层的快照中找到该文件指向下层文件的指针。

再从下层0xf33位置指针指向的数据块中读取的数据到容器的存储区

最后将数据前往app。

在写入数据时还需求依据数据的大小先央求1~N个64K的容器快照，用于保存拷贝的块数据。

DeviceMapper的块操作看上去很美，实践上存在很多成绩，比如频繁操作较小文件时需求不停地从资源池中分配数据库并映射到容器中，这样效率会变得很低，且DeviceMapper每次镜像运转时都需求拷贝一切的镜像层信息到内存中，当启动多个镜像时会占用很大的内存空间。

针对不同的storage-driver我们用上述etcd的dockerfile停止了一组构建测试

注：该数据因dockerfile以及操作系统、文件系统、网络环境的不同测试结果能够会存在较大差异

我们发如今该实验场景下DevivceMapper在时间上清楚会逊于AUFS和Overlay2，而AUFS和Overlay2基本相当，当然该数据仅能作为一个参考，实践构建还遭到详细的Dockerfile内容以及操作系统、文件系统、网络环境等多方面的影响，那要怎样样才能尽量让构建时间最短提升我们的任务效率呢?

且看下回分解!

【编辑引荐】

清点：十二“发行版Kubernetes”，引领容器革命！

展望2019：容器云战晋级，全栈云大势所趋

部署容器时要思索的6个关键要素

数据中心容器网络技术

容器赋能AI-人工智能在360私有云容器效劳上的实际

(责任编辑：admin)