Docker容器中文件查找的工作原理

根据，每个Dockerfile指令都会创建一个层，在基于旧图像创建新图像时，所有层都会保留。然后，当我创建自己的图像时，可能会涉及数百层，因为递归继承了基本图像的层

据我所知，容器中的文件查找的工作方式如下：

若要访问文件a，请从w/r层中的容器层开始查找。 UnionFS检查此层是否有记录，并将其标记为已删除。如果是，则返回它或分别说“未找到”，结束查找。如果没有，将任务传递到下面的层。 查找将在底层结束。

如果是这样的话，考虑一个驻留在底层和其他层不变的文件，/bin /sH可能需要通过所有层到底部。虽然图层可能很轻，但查找仍然需要比常规图层100倍的时间，这是显而易见的。但根据我的经验，Docker相当快，几乎和原生操作系统一样。我哪里错了？

这一切都要感谢和

直接来自维基百科：

它允许单独文件系统的文件和目录，称为 要透明覆盖的分支，形成一个连贯的文件 系统

从一个有趣的角度：

在内核中，文件系统按装载顺序堆叠 顺序，第一个装入的文件系统位于装入的底部 堆栈，最新的装载在堆栈的顶部。只有文件 并且可以看到装载堆栈顶部的目录。联合 装载时，来自较低文件系统的目录项与 上层文件系统的目录项，从而使 所有装载的文件系统的组合。文件中具有相同名称的文件 较低的文件系统被屏蔽，因为较高的文件系统优先

因此，它不会按照传统的方式（例如一次一层）遍历层，而是在任何给定的时间知道哪个文件驻留在哪个磁盘上

在文件系统层这样做也意味着软件不必担心文件驻留在哪里，它知道请求/bin/sh，文件系统知道从哪里获取它

更多信息可以在这里找到

所以要回答你的问题： 我错在哪里

---

您认为它必须一次查看一个层，而不必这样做。真是太棒了

为了补充前面的正确答案，写时拷贝CoW和union文件系统实现人员希望具有接近本机的性能，因此，当然，他们已经调整了实现和API，以获得最佳的查找/文件系统性能

也就是说，Docker并不是只在一个“类型”的union/CoW文件系统上运行，而是有一个小的可用选项数组，默认值取决于安装它的Linux发行版

AUF和overlayfs是最常见的，但Docker还支持在Fedora/RHEL/CentOS、btrfs和zfs上提供和支持的devicemapper Red Hat。我对可能感兴趣的各种选择进行了比较和对比