覆盖存储驱动程序内部

Question

这个问题的后续报道。

我在码头仓库司机上的进一步阅读显示，overlay驱动程序使用硬链接实现将所有图像层合并到较低层，这会导致过多的inode利用率。有人能解释一下吗？据我所知，创建硬链接并不会创建新的inode。

Answer 1

OverlayFS是一个联合文件系统，在Docker级别有两个存储驱动程序使用它:原始/旧版本名为overlay和更新版本名为overlay2。在OverlayFS中，有一个较低级别的目录被公开为只读目录.在这个目录的顶部是上层目录，它允许读写访问.这些目录中的每一个都称为一个层。下级目录和上层目录的组合视图被表示为一个单一的单元，称为“合并”目录。

新的overlay2存储驱动程序本机支持多达128个这样的层。旧的overlay驱动程序一次只能使用两个层。由于大多数Docker映像是使用多层构建的，因此这一限制相当明显。为了解决这个限制，每个层都作为一个单独的目录来实现，该目录模拟一个完整的映像。

为了检查测试系统上的差异，我从Docker中提取了“ubuntu”映像，并检查了overlay2和overlay驱动程序之间目录结构的差异：

[root@testvm1 overlay2]$ ls */diff
4864f14e58c1d6d5e7904449882b9369c0c0d5e1347b8d6faa7f40dafcc9d231/diff:
run

4abcfa714b4de6a7f1dd092070b1e109e8650a7a9f9900b6d4c3a7ca441b8780/diff:
var

a58c4e78232ff36b2903ecaab2ec288a092e6fc55a694e5e2d7822bf98d2c214/diff:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

c3f1a237c46ed330a2fd05ab2a0b6dcc17ad08686bd8dc49ecfada8d85b93a00/diff:
etc  sbin  usr  var


[root@testvm1 overlay]# ls */root/
001311c618ad7b94d4dc9586f26e421906e7ebf5c28996463a355abcdcd501bf/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

048f81f400f7d74f969c4fdaff6553c782d12c04890ad869d75313505c868fbc/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

8060f0c647f24050e1a4bff71096ffdf9665bff26e6187add87ecb8a18532af9/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

fbdef944657234468ee55b12c7910aa495d13936417f9eb905cdc39a40fb5361/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

在overlay表示中，每个层模拟一个完整的图像，而overlay2层只包含层间的确切差异。在overlay驱动程序的方法中，硬链接被用作节省不同层间空间的方法。然而，这种方法仍然不完善，当图像数据包含符号链接和字符设备等特殊文件时，需要新的索引。这很快就会产生大量的节点。

在我的测试系统中，overlay2和overlay驱动程序之间的inode分布如下所示。

[root@testvm1 overlay2]$ du --inodes -s *
8       4864f14e58c1d6d5e7904449882b9369c0c0d5e1347b8d6faa7f40dafcc9d231
27      4abcfa714b4de6a7f1dd092070b1e109e8650a7a9f9900b6d4c3a7ca441b8780
3311    a58c4e78232ff36b2903ecaab2ec288a092e6fc55a694e5e2d7822bf98d2c214
1       backingFsBlockDev
25      c3f1a237c46ed330a2fd05ab2a0b6dcc17ad08686bd8dc49ecfada8d85b93a00
5       l

[root@testvm1 overlay]# du --inodes -s *
3298    001311c618ad7b94d4dc9586f26e421906e7ebf5c28996463a355abcdcd501bf
783     048f81f400f7d74f969c4fdaff6553c782d12c04890ad869d75313505c868fbc
768     8060f0c647f24050e1a4bff71096ffdf9665bff26e6187add87ecb8a18532af9
765     fbdef944657234468ee55b12c7910aa495d13936417f9eb905cdc39a40fb5361

在我的系统中，overlay2上的inode总数达到3378。使用overlay，这个计数将上升到5615。这个值考虑的是单个映像，并且没有容器运行，因此一个拥有大量码头容器和图像的大型系统可以很快达到支持文件系统(XFS或EXT4，/var/lib/docker/overlay目录所在的位置)所施加的inode限制。

由于这个原因，更新的overlay2存储驱动程序目前是大多数新安装的推荐选项。从Dockerv18.09开始，overlay驱动程序就不再受欢迎，预计在以后的版本中将被删除。