如何在Docker容器中查找文件
根据Docker文档 ，每个Dockerfile指令都会创build一个图层，当您基于旧图像创build新图像时，所有图层都会保留。 然后，当我创build自己的图像时，由于基本图像层的recursioninheritance，可能会涉及数百个图层。
据我了解，容器中的文件查找工作是这样的：
- 进程想要访问文件
a，lookup从容器层开始（thin w / r layer）。 - UnionFS检查这个图层是否有一个logging（把它或者标记为已删除）。 如果是，则返回或分别找不到，结束查找。 如果不是，则将任务传递到下面的图层。
- 查找结束在底层。
如果是这样的话，考虑一个驻留在底层的文件，其他层不改变， /bin/sh可能需要经过所有层到底层。 虽然图层可能非常轻，但查找仍然需要100倍以上的时间，显而易见。 但是从我的经验来看，Docker非常快，几乎和原生操作系统一样。 我错在哪里？
这都是为了感谢UnionFS和Union坐骑 ！
直接从维基百科：
它允许单独的文件系统（称为分支）的文件和目录被透明地覆盖 ，形成一个统一的文件系统。
从一篇有趣的文章 ：
在内核中，文件系统按照其安装顺序堆叠，第一个安装的文件系统位于安装堆栈的底部，最新的安装位于堆栈的顶部。 只有安装堆栈顶部的文件和目录是可见的。 使用联合安装，来自较低文件系统的目录条目与较高文件系统的目录条目合并，从而使所有已安装文件系统的逻辑组合。 在较低的文件系统中具有相同名称的文件被屏蔽，因为较高的文件优先。
因此，它不会像传统意义上的那样“遍历图层”（例如，一次一个），而是知道（在任何给定的时间）哪个文件驻留在哪个磁盘上。
在文件系统层执行此操作也意味着没有任何软件需要担心文件的驻留位置，它知道要求/bin/sh ，文件系统知道从哪里得到它。
更多信息可以在这个networking研讨会中find。
所以要回答你的问题：
我错在哪里？
你认为它必须一次一层地查看图层，而不必这样做。 （UnionFS太棒了！）
为了增加正确的先前答案，写时复制（CoW）和联合文件系统实现者希望具有接近本机的性能，所以当然已经调整了它们的实现和“API”以具有最佳的查找/文件系统性能。
也就是说，了解Docker并不仅仅是联合/ CoW文件系统的一种“types”之上，而是有一小部分可用的选项，默认值取决于它所安装的Linux发行版。
AUFS和overlay（fs）是最常见的，但是Docker也支持devicemapper（Red Hat在Fedora / RHEL / CentOS上贡献和支持），btrfs和zfs。 我有一篇博客文章比较和对比可能感兴趣的各种选项。