overlay，以及更新更稳定的 overlay2。Note：如果你使用 OverlayFS，使用overlay2而不是overlay驱动，因为overlay2在 inode 利用率上更高效。要使用新的驱动，你需要系统内核版本 4.0 或者更高版本，除非你是使用 RHEL 或者 CentOS 用户，此时需要内核版本在 3.10.0-514 或更高版本。
overlay，满足条件下优先使用 overlay2d_type=true 必须开启。使用 xfs_info 验证 ftype 选项是否为 1。docker save 保存镜像或推送到 Docker Hub（也可以是内部私有镜像仓库），防止镜像丢失overlay 或 overlay2 驱动/etc/docker/daemon.json 加入 overlay2 存储配置项，重启 docker daemon 即可生效。overlay2 驱动是如何工作的lowerdir，上层目录称为 upperdir，统一视图通过称为 merged 自身目录暴露。overlay 驱动仅适用单个 lower OverlayFS 层，因此需要通过硬链接来实现多层镜像，overlay2 驱动原生支持 128 个 lower OverlayFS 层。这个功能为与层相关的命令如 docker build 和 docker commit 提供了更好的性能，并且在后备文件系统上消耗更少的 inode。docker pull ubuntu 下载一个五层镜像后，你可以在 /var/lib/docker/overlay2 目录下看到 6 个目录。l（小写 L） 目录包含缩短的层标识符作为软链接，这些标识符用于避免 mount 命令参数页面大小限制。link 的文件，其中包含缩短标识符的名称，以及一个包含镜像内容的名为 diff 的目录。lower 的文件，表示其父级，以及包含这层镜像内容的名为 diff 的目录。它包含一个 merged 目录，包括父层以及自身的统一内容，以及 OverlayFS 自身使用的 work 目录。mount 命令查看 Docker 使用 overlay2 存储驱动的挂载情况：rw 选项显示 overlay 是读写方式挂载的。overlay 驱动是如何工作的lowerdir，上层目录称为 upperdir，统一视图通过称为 merged 自身目录暴露。lowerdir，容器层术语 upperdir。统一视图通过名为 merged 的目录暴露。overlay 驱动仅适用于两层，这意味着多层镜像不能实现多个 OverlayFS 层。取而代之，每个镜像层都在 /var/lib/docker/overlay 下实现自己的目录。通过硬链接引用与底层共享数据的方式来节省空间。从 Docker 1.10 开始，镜像层 IDs 不再对应于 /var/lib/docker 中的目录名。overlay 驱动组合顶层的目录以及容器的新目录。镜像的顶层是叠加层中的 lowerdir，并且是只读挂载的。容器的新目录是 upperdir 并且是可写的。docker pull 命令暂时了一个 Docker 主机下载一个包含五层的 Docker 镜像。/var/lib/docker/overlay/ 目录下有自己的目录。/var/lib/docker/overlay/ 目录下。如果你使用 ls -l 命令列出运行容器的子目录，可以看到三个目录和一个文件存在：lower-id 文件包含了容器所基于的镜像的顶层 ID，即 OverlayFS lowerdir。upper 目录包含容器读写层的内容，对应 OverlayFS 中的 upperdir。merged 目录是 lowerdir 和 upperdir 的联合挂载，包含正在运行的容器文件系统视图。work 目录是 OverlayFS 内部目录。mount 命令查看 Docker 使用 overlay 存储驱动的挂载情况：rw 选项显示 overlay 是读写方式挂载的。overlay 或 overlay2 读写的overlay 打开文件读取的场景。upperdir），则从镜像层（lowerdir）读取该文件。这会导致很少的性能开销。upperdir）但不存在于镜像层（lowerdir）的文件，则直接从容器层中读取该文件。upperdir）和镜像层（lowerdir）的文件，则容器层（upperdir）会覆盖镜像层（lowerdir） 相同名字的文件。upperdir）。overlay/overlay2 驱动程序从镜像层（lowerdir）执行一个 copy_up 操作到容器层（upperdir）。然后，容器将更改写入容器层中的文件的新副本。但是，OverlayFS 工作在文件级别而不是块级别，意味着所有 OverlayFS copy_up 操作都会复制整个文件，即使文件非常大，并且只修改了其中的一小部分。这就对容器写入性能产生显著的影响。不过，有两件事值得注意：copy_up 操作仅在第一次写入文件时发生，对同一文件的后续写入操作只对已复制到容器的文件副本进行操作。overlay 和 overlay2，overlayfs2 在初始读取时的性能略低于 overlayfs，因为它会查看更多层级，但是它会缓存结果。upperdir）中创建一个 whiteout 文件。镜像层（lowerdir）中文件的版本并不会被删除（因为 lowerdir 是只读的）。但是，whiteout 文件会阻止其在容器中可用。当在容器中删除目录时，会在容器层（upperdir）中创建一个 opaque 目录。它的工作机制同 whiteout，并且有效地防止目录被访问，即使它仍然存在于镜像层（lowerdir）。rename(2)，否则会返回 EXDEV error（"cross-device link not permitted"）。overlay2 和 overlay 驱动比 aufs 和 devicemapper 拥有更好的性能。在某些情况下，overlay2 的性能表现可能比 btrfs 还要好。不过要注意以下几点：overlay 和 overlay2 驱动高效利用内存以及高密度使用案例的优先选择如 PaaS。copy_up 比 AUFS 同样的操作要更快，因为 AUFS 比 OverlayFS 拥有更多的层级，如果在多个 AUFS 层级搜索可能会造成大的延迟。overlay2 也支持多层，但通过缓存减轻了性能损失。overlay 存储驱动会导致过多的 inode 损耗。特别是 Docker 主机上存在大量的镜像和容器时尤为明显。格式化文件系统增加可用的 inode 数量是唯一的解决方式。为了避免这个问题，因此建议尽可能的使用 overlay2。fd1=open("foo", O_RDONLY) 和 fd2=open("foo", O_RDWR)。在这个案例中，你的应用期望 fd1 和 fd2 引用同一个文件。但是，因为发生了 copy-up 操作导致第二次调用 open(2)，文件描述符指向的是不同的文件。fd1 继续引用镜像层（lowerdir）而 fd2 引用的文件在容器层（upperdir）。解决方式是 touch 这些文件，引发 copy-up 操作发生。所有的后续 open(2) 操作无论是读写访问模式都引用容器层(upperdir)的文件。yum 是已知受影响的，除非 yum-plugin-ovl 已经安装了。如果 yum-plugin-ovl 包在你的发行版中不可用如 RHEL/CentOS 6.8 或 7.2，你可能需要在运行 yum install 前执行 touch /var/lib/rpm/*。yum-plugin-ovl 软件包实现了针对 yum 的 touch 变通方案。rename(2) 系统调用。你的应用需要检测它的失败以及返回 "copy and unlink" 策略。