overlay文件系统浅析（由于某些原因，找不到参考的原出处了，暂时写原创，若原作者看到，还请留言）

overlayfs文件系统类似于aufs，相比aufs，overlay实现更简洁，很早就合入了linux主线， 合入主线后overlayfs修改为overlay。

docker 使用overlay文件系统来构建和管理镜像与容器的磁盘结构。

overlay文件系统分为lowerdir、upperdir、merged， 对外统一展示为merged，uperdir和lower的同名文件会被upperdir覆盖。具体层次如下

overlay的使用方法：

[root@ops2-1 /var/lib/docker/overlay]
#mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged

注：workdir必须和upperdir是mount在同一个文件系统下， 而lower不是必须的

lower目录可以是一个目录链

mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work /merged

如果没有upperdir， merged是只读的

#mount -t overlay overlay -o lowerdir=/lower1:/lower2 /merged

Usage

To mount an overlay use the following mount options:

#mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work /merged

Note: The working directory (workdir) needs to be an empty directory on the same filesystem mount as the upper directory.

The lower directory can actually be a list of directories separated by :, all changes in the merged directory are still reflected in upper.

Example:

#mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work /merged

Note: The order of lower directories is the rightmost is the lowest, thus the upper directory is on top of the first directory in the left-to-right list of lower directories; NOT on top of the last directory in the list, as the order (or logic) might seem to suggest.

The above example will have the order:

/upper
/lower1
/lower2
/lower3

To add an overlayfs entry to /etc/fstab use the following format:

/etc/fstab

overlay /merged overlay noauto,x-systemd.automount,lowerdir=/lower,upperdir=/upper,workdir=/work 0 0

The noauto and x-systemd.automount mount options are necessary to prevent systemd from hanging on boot because it failed to mount the overlay. The overlay is now mounted whenever it is first accessed and requests are buffered until it is ready. See fstab#Automount with systemd.
Read-only overlay

Sometimes, it is only desired to create a read-only view of the combination of two or more directories. In that case, it can be created in an easier manner, as the directories upper and work are not required:

#mount -t overlay overlay -o lowerdir=/lower1:/lower2 /merged

When upperdir is not specified, the overlay is automatically mounted as read-only.

OverlayFS
介绍

OverlayFS是一种堆叠文件系统，它依赖并建立在其它的文件系统之上（例如ext4fs和xfs等等），并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行“合并”，然后向用户呈现，这也就是联合挂载技术，对比于AUFS，OverlayFS速度更快，实现更简单。 而Linux 内核为Docker提供的OverlayFS驱动有两种：overlay和overlay2。而overlay2是相对于overlay的一种改进，在inode利用率方面比overlay更有效。但是overlay有环境需求：docker版本17.06.02+，宿主机文件系统需要是ext4或xfs格式。
联合挂载

overlayfs通过三个目录：lower目录、upper目录、以及work目录实现，其中lower目录可以是多个，work目录为工作基础目录，挂载后内容会被清空，且在使用过程中其内容用户不可见，最后联合挂载完成给用户呈现的统一视图称为为merged目录。以下使用mount将演示其如何工作的。

使用mount命令挂载overlayfs语法如下：

mount -t overlay overlay -o lowerdir=lower1:lower2:lower3,upperdir=upper,workdir=work merged_dir

创建三个目录A、B、C,以及worker目录：

然后使用mount联合挂载到/tmp/test 下：

然后我们再去查看/tmp/test目录，你会发现目录A、B、C被合并到了一起,并且相同文件名的文件会进行“覆盖”，这里覆盖并不是真正的覆盖，而是当合并时候目录中两个文件名称都相同时，merged层目录会显示离它最近层的文件：

同时我们还可以通过mount命令查看其挂载的选项：

以上这样的方式也就是联合挂载技术。

1、在一个支持 overlay文件系统的 Linux (内核3.18以上)的操作系统上一个同级目录内（如/root下）创建四个文件目录 lower 、upper 、merged 、work其中 lower 和 upper 文件夹的内容如上图所示，merged 和work 为空，same文件名相同，内容不同。
2、在/root目录下执行如下挂载命令，可以看到空的merged文件夹里已经包含了 lower 及 upper 文件夹中的所有文件及目录。
$mount -t overlay overlay -olowerdir=./lower,upperdir=./upper,workdir=./work ./merged
3、使用df –h 命令可以看到新构建的 overlay 文件系统已挂载。
Filesystem Size Used Avail Use% Mounted on
overlay 20G 13G 7.8G 62% /root /merged

 

那么 lower 和 upper 目录里有相同的文件夹及相同的文件，合并到 merged 目录里时显示的是哪个呢？规则如下：

文件名及目录不相同，则 lower 及 upper 目录中的文件及目录按原结构都融入到 merged 目录中；
文件名相同，只显示 upper 层的文件。如上图在 lower 和 upper 目录下及下层目录 dir_A 下都有 same.txt 文件，但在合并到 merged 目录时，则只显示 upper 的，而 lower 的隐藏 ;
目录名相同， 对目录进行合并成一个目录。如上图在 lower 及 upper 目录下都有 dir_A 目录，将目录及目录下的所有文件合并到 merged 的 dir_A 目录，目录内如有文件名相同，则同样只显示 upper 的，如上图中 dir_A 目录下的same.txt文件。
overlay只支持两层，upper文件系统通常是可写的；lower文件系统则是只读，这就表示着，当我们对 overlay 文件系统做任何的变更，都只会修改 upper 文件系统中的文件。那下面看一下overlay文件系统的读，写，删除操作。

读
¬ 读 upper 没有而 lower 有的文件时，需从 lower 读；
¬ 读只在 upper 有的文件时，则直接从 upper 读
¬ 读 lower 和 upper 都有的文件时，则直接从 upper 读。

写
¬ 对只在 upper 有的文件时，则直接在 upper 写
¬ 对在lower 和 upper 都有的文件时，则直接在 upper 写。
¬ 对只在 lower 有的文件写时，则会做一个copy_up 的操作，先从 lower将文件拷贝一份到upper，同时为文件创建一个硬链接。此时可以看到 upper 目录下生成了两个新文件，写的操作只对从lower 复制到 upper 的文件生效，而 lower 还是原文件。

删
¬ 删除 lower 和 upper 都有的文件时，upper 的会被删除，在 upper 目录下创建一个 ‘without’ 文件，而 lower 的不会被删除。
¬ 删除 lower 有而 upper 没有的文件时，会为被删除的文件在 upper 目录下创建一个 ‘without’ 文件，而 lower 的不会被删除。
¬ 删除 lower 和 upper 都有的目录时，upper 的会被删除，在 upper 目录下创建一个类似‘without’ 文件的 ‘opaque’ 目录，而 lower 的不会被删除。

可以看到，因为 lower 是只读，所以无论对 lower 上的文件和目录做任何的操作都不会对 lower 做变更。所有的操作都是对在 upper 做， 。

copy_up只在第一次写时对文件做copy_up操作，后面的操作都不再需要做copy_up，都只操作这个文件，特别适合大文件的场景。overlay的 copy_up操作要比AUFS相同的操作要快，因为AUFS有很多层，在穿过很多层时可能会有延迟，而overlay 只有两层。而且overlay在2014年并入linux kernel mailline ，但是aufs并没有被并入linux kernel mailline ，所以overlay 可能会比AUFS快。

lower文件系统可以为任何linux支持的文件系统，甚至可以为另一个overlayfs。因为虽然overlay文件系统的底层是由两个文件系统构成，但它本身只是一个文件系统，就如前面用df命令看到的，所以也可以和其他文件系统组成新的overlay文件系统。而upper是可写的，不支持NFS。多层 lower 可执行如下命令：
$mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 ,upperdir=./upper,workdir=./work ./merged
上例中，lower 是由三个文件系统合并成一个文件系统，其中lower1在最上面，lower3在最底下。
Docker一直在用AUFS（高级多层次统一文件系统）作为容器的文件系统。AUFS是一个能透明覆盖一或多个现有文件系统的层状文件系统。当一个进程需要修改一个文件时，AUFS创建该文件的一个副本。AUFS可以把多层合并成文件系统的单层表示。Docker 的image构采用的是AUFS，每个新版本都是一个与之前版本的简单差异改动，有效地保持镜像文件最小化。那docker 使用 overlay 之后有什么区别呢？
首先镜像在下载时每一层的镜像都有一个自己的镜像ID，每个镜像都会有自己的目录，保存在/var/lib/docker/overlay目录下，但是这些层目录的名字并不是下载镜像时的ID名称。我们都知道AUFS是多层，那如何体现为两层呢？启动一个容器后，也在这个目录下产生一个层目录，进入到目录可以看到有三个文件夹，分别是merged，upper，work，和一个文件lower-id，而在lower-id中保存的就是镜像最上层的ID，所以对容器来说，还是一个两层的文件系统。

这里说明一下，docker pull image时显示的镜像ID名称与/var/lib/docker/overlay目录下的镜像目录名称不一样。镜像目录中保存的是这层独有的文件和硬链接下层共享的文件。这样可以更有效的利用磁盘资源。
从上面这个图可以看到，overlay的两层对应的就是docker的镜像层（只读）和容器层（可写），只是把原来AUFS中的多层镜像合并成了lower层，而upper层代表的是容器层。

我们看到虽然overlay和AUFS都是联合文件系统，但结构比AUFS简单，且并入了linux kernel mainline，可能会比AUFS快，但还是太年轻，要谨慎在生产使用。而AUFS做为docker的第一个存储驱动，已经有很长的历史，比较的稳定，且在大量的生产中实践过，有较强的社区支持。
————————————————
版权声明：本文为CSDN博主「JL-LOVE」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a985588764/article/details/101024357