Linux AUFS 文件系统

主要回答的问题

aufs原始的用途
aufs的普通演示
aufs在docker中的使用的演示
aufs，overlays的架构
明白docker镜像的本质只是文件.
docker容器就是在镜像层上又增加了可读写的容器层，然后联合挂载到宿主机的一个挂载点上。使得运行时对容器的所有修改都只针对这个容器层，不影响镜像文件
aufs缺点,overlays优点
aufs没有加入linux内核, ubuntu默认支持,centos默认不支持。

设置CentOS支持aufs

[/sys/fs/aufs/目录]

/sys/fs目录按照设计是用于描述系统中所有文件系统，包括文件系统本身和按文件系统分类存放的已挂载点，但目前只有 fuse,gfs2 等少数文件系统支持 sysfs 接口，一些传统的虚拟文件系统(VFS)层次控制参数仍然在 sysctl (/proc/sys/fs) 接口中中；
使用 /sys 文件系统访问 Linux 内核
sysfs 虚拟文件系统提供了一种比 proc 更为理想的访问内核数据的途径

https://www.ibm.com/developerworks/cn/linux/l-cn-sysfs/index.html

root@192:/tmp/aufs# ls /sys/fs/ 
aufs  bpf  cgroup  ecryptfs  ext4  fuse  pstore
root@192:/tmp/aufs# ls /sys/fs/ext4/
features  sda1
root@192:/tmp/aufs# ls /sys/fs/aufs/
config  si_e8bf3ef3161c9271

aufs的架构

只读层+读写层 mount> 宿主机的union挂载点, 作为容器的根目录。
只读层就是镜像，读写层是执行docker run时新增的容器层, 对容器的修改就是对union挂载点的修改，只影响读写层。
直接修改宿主机的挂载点,也就是修改容器的根目录，反之亦然。

aufs的关键技术

看起来这个虚拟后的联合文件系统是可以对任何文件进行操作的，但是其实它并没有改变原来的文件。这是因为 Union File System 用到了一个重要的资源管理技术：写时复制。

但是 aufs 出现的时间要比 docker 长很多，它常见的用法包括

参考附录1

Linux 光盘演示和教程，录制了 Linux 的光盘可以用来让用户体验，但是光盘的内容是只读的，可以通过 aufs 把光盘和 U 盘或者磁盘 mount 到一起，用户对文件的修改保存到后面的存储上
如果系统上因为各种原因，不同用户的 home 目录保存在不同的路径和磁盘上，可以通过 aufs 把它们 mount 到一起，统一进行操作

AUFS演示

centos默认是没有启动aufs的，然后安装过程中出现了不少问题，所以就用ubuntu来演示了。

第一个例子

参考附录1

base 作为底层的目录
top 作为上层的目录
mnt： aufs 使用的挂载点，会把上面两个目录挂载到这里

第2个例子

参考附录2(包含图示讲解)

// 挂载后未修改时，container-layer目录有1个文件
root@192:/tmp/aufs# tree
.
├── container-layer
│   └── container-layer.txt
├── image-layer1
│   ├── image-layer1.txt
│   └── subdir1
│       └── subdir1.txt
├── image-layer2
│   ├── image-layer2.txt
│   └── subdir2
│       └── subdir2.txt
├── image-layer3
│   ├── image-layer3.txt
│   └── subdir3
│       └── subdir3.txt
├── mnt
│   ├── container-layer.txt
│   ├── image-layer1.txt
│   ├── image-layer2.txt
│   ├── image-layer3.txt
│   ├── subdir1
│   │   └── subdir1.txt
│   ├── subdir2
│   │   └── subdir2.txt
│   └── subdir3
│       └── subdir3.txt
└── run.sh

11 directories, 15 files
// 2. 对rw层(readwrite)的文件进行修改。直接修改。
root@192:/tmp/aufs# echo 666 > ./mnt/container-layer.txt
root@192:/tmp/aufs# cat container-layer/container-layer.txt
666
// 3. 对ro层(readonly)的文件进行修改。copy到rw读写层之后再wrtie。(copy on write)
root@192:/tmp/aufs# echo 777 > ./mnt/image-layer1.txt
root@192:/tmp/aufs# cat image-layer1/image-layer1.txt
I am image layer 1
root@192:/tmp/aufs# cat ./mnt/image-layer1.txt
777
// 4. 对ro层进行修改后的目录树,container-layer目录(rw层)增加了1个文件
root@192:/tmp/aufs# tree
.
├── container-layer
│   ├── container-layer.txt
│   └── image-layer1.txt //  ydd:这是copy on write的文件
├── image-layer1
│   ├── image-layer1.txt
│   └── subdir1
│       └── subdir1.txt
├── image-layer2
│   ├── image-layer2.txt
│   └── subdir2
│       └── subdir2.txt
├── image-layer3
│   ├── image-layer3.txt
│   └── subdir3
│       └── subdir3.txt
├── mnt
│   ├── container-layer.txt
│   ├── image-layer1.txt
│   ├── image-layer2.txt
│   ├── image-layer3.txt
│   ├── subdir1
│   │   └── subdir1.txt
│   ├── subdir2
│   │   └── subdir2.txt
│   └── subdir3
│       └── subdir3.txt
└── run.sh

11 directories, 16 files

演示docker使用aufs作为storage driver

借助这个场景来理解:宿主机如何往运行中的docker容器中传输文件--Q: docker运行中的容器又是存在哪里的

AUFS的缺点

参考附录1

最大的问题是它不没有进入到 Linux 内核，因此不能保证可移植性，虽然像 ubuntu 这种发行版默认支持 aufs，但并不是所有系统都如此，比如centos 就默认没有提供 aufs 支持。之所以没有合并到内核，据说是因为 aufs 的实现代码很冗杂，Linus 认为代码质量太差，虽然开发者多次精简，最终还是没有进入到内核，而且在短时间内也不会有什么变化。
我们至少能看到两个性能问题：第一次修改一个大文件会非常耗时；另外层级过多也会影响整体的读写性能。

docker默认的存储驱动已经演进到了overlay2

overlay架构 / /附录5
附录3
虽然当前 docker 默认的存储驱动已经演进到了 overlay2，但是学习 AUFS 依然可以帮助我们深入理解 docker 中的文件系统。
附录4
在最新的 Docker 中，overlay2 取代了 aufs 成为了推荐的存储驱动，但是在没有 overlay2 驱动的机器上仍然会使用 aufs 作为 Docker 的默认驱动。

其他对容器镜像的理解

附录4

Docker 镜像其实本质就是一个压缩包，我们可以使用下面的命令将一个 Docker 镜像中的文件导出：
容器和镜像的区别就在于，所有的镜像都是只读的，而每一个容器其实等于镜像加上一个可读写的层，也就是同一个镜像可以对应多个容器。

Docker五种存储驱动原理及应用场景和性能测试对比 // TODO