docker实现文件改动的原理

由于工作需要我需要知道当我在容器中修改或删除一个文件时，该容器的可写层将会存储什么。

为了测试，我从alpine镜像运行myalpine容器，在/home目录中创建两个目录来测试删除和修改文件，提交为镜像后看到新层内容如下：

 然后修改testE的内容，删除testR，再提交容器为新的镜像myalpine01

得到myalpine01新层内容如下：

其中testE完全就是我修改后的testE文件

而testRemove只剩下了空目录，因为前面的层都是只读的，那这里光一个空目录如何实现对前面层中testR文件的删除呢？

vim testRemove发现有一个隐藏的文件.wh.testR

 干嘛用的？

查找了一下得到如下结论：

当我们需要修改文件file1时，Device Mapper 中的写时复制技术会将镜像层中的文件file1直接拷贝到最上层的top branch，然后再进行修改，即我们修改的其实是从底层拷贝的文件：

        当我们需要删除文件file1时，由于文件file1是镜像层的文件，此时会在容器最上层中创建一个.wh开头的隐藏文件，从而将文件file1隐藏掉，所以文件file1并未被删除掉，这样也就保证了镜像层数据的完整性和复用性。——参考自Device Mapper写时复制技术_gyamtf@amtf.jlsj的博客-CSDN博客

如果要删除file1，AUFS会在container的read-write层生成一个.wh.file1的文件来隐藏所有read-only层的file1文件。——参考自Docker之Linux UnionFS_贾诩是也的博客-CSDN博客

Docker 使用 Copy-On-Write 技术来实现更改。具体来说，当在容器中删除文件时，Docker 实际上并不删除文件，而是在可写层中创建一个与该文件相同的占位符。当需要读取该文件时，Docker 将首先检查可写层是否包含该文件的占位符，如果是，则返回占位符；否则，它会检查底层镜像层是否包含该文件，如果是，则返回该文件。因此，即使在容器层中删除了文件，原始镜像层中的文件仍然存在，并可以从底层镜像中访问。

占位符文件实际上只是一个零字节文件，其中包含了有关被删除文件的元数据信息，如文件名、权限、时间戳等。为了确定哪个占位符文件代表哪个被删除的文件，Docker 使用文件系统的 inode（索引节点）和文件名来进行匹配。每个文件系统都会分配一个唯一的 inode 号码给每个文件和目录，而文件名则是唯一的文件标识符。因此，当您删除文件时，Docker 会记录被删除文件的 inode 和文件名，并在可写层中创建一个占位符文件，它的 inode 和文件名与被删除文件相同。当需要读取被删除文件时，Docker 将使用 inode 和文件名来查找相应的占位符文件，并返回相应的元数据信息。

当需要读取被删除文件时，Docker 将使用 inode 和文件名来查找相应的占位符文件，并返回相应的元数据信息，但不会返回文件内容。            ——chatGPT