☰

覆盖存储驱动程序内部结构

tag-icon • tag-icon docker inode hard-link
覆盖存储驱动程序内部结构

后续行动来自这个问题。

我的进一步阅读Docker 存储驱动程序据透露，overlay驱动程序使用硬链接实现将所有图像层合并到较低层，这会导致索引节点利用率过高。有人可以解释一下吗？据我所知，创建硬链接并不会创建新的索引节点。

答案1

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

较新的overlay2存储驱动程序本身支持最多 128 个此类层。较旧的overlay驱动程序一次只能处理两层。由于大多数 Docker 镜像都是使用多层构建的，因此这个限制相当重要。为了解决此限制，每个层都实现为模拟完整图像的单独目录。

为了检查我的测试系统上的差异，我从 Docker Hub 中提取了“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驱动程序的方法中，使用硬链接来节省不同层之间的空间。但这种方法仍然不完美，当图像数据包含符号链接、字符设备等特殊文件时，需要新的inode。这可以快速增加大量的索引节点。

我的测试系统上的inodeoverlay2和overlay驱动程序之间的分布如下所示。

[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

我的系统上的 inode 总数overlay2达到 3378。使用overlay，此计数上升到 5615。此值考虑的是单个映像且没有运行容器，因此具有大量 docker 容器和映像的大型系统可能会很快达到支持文件系统（XFS 或 EXT4、目录/var/lib/docker/overlay所在的位置）。

因此，overlay2目前大多数新安装都建议选择较新的存储驱动程序。该overlay驱动程序自 Docker v18.09 起已弃用，预计将在未来版本中删除。

相关内容