主页 / unix / 问题 / 510931
Accepted
Rajnish Kumar Soni
Asked: 2019-04-07 09:30:57 +0800 CST

覆盖存储驱动程序内部

  • 772

这个问题的后续行动。

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

docker inode

1 个回答

  1. Best Answer

    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。这可以快速增加大量的 inode。

    overlay2我的测试系统上的和驱动程序之间的inode分布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 起已弃用，预计将在未来版本中删除。

    • 2

相关问题