Complete Dockerfile instruction reference list

04_image/4.7_internal.md

@@ -40,8 +40,8 @@ flowchart TD
 ```
 
 *   **读取文件**：当容器需要读取文件时，Docker 会从最上层 (容器层) 开始向下层 (镜像层) 寻找，直到找到该文件为止。
-*   **修改文件**：当容器需要修改某个文件时，底层存储后端会以 **写时复制 (Copy-on-Write，CoW)** 的方式记录变化。在 `overlay2` 这类联合文件系统后端上，常见表现是先把文件 `copy_up` 到容器层再修改；而 `btrfs`、`zfs` 等 CoW 文件系统的内部实现会有所不同。
-*   **删除文件**：当容器删除某个文件时，Docker 不会直接改写下层只读层，而是由当前存储后端在上层记录“把下层内容屏蔽掉”的元数据。在 `overlay2` 中，这常表现为 whiteout 或 opaque directory；其他后端会用各自的机制达到相同效果。
+*   **修改文件**：当容器需要修改某个文件时，Docker 会从下层镜像中将该文件复制到上层的容器层，然后对副本进行修改。这被称为 **写时复制 (Copy-on-Write，CoW)** 策略。
+*   **删除文件**：当容器删除某个文件时，Docker 并不是真的去下层删除它 (因为下层是只读的)，而是在容器层创建一个特殊的 “白障 (Whiteout)” 文件，用来标记该文件已被删除，从而在容器视图中隐藏它。
 
 这就是为什么：
 
@@ -58,10 +58,10 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
 
 ### 4.7.4 联合文件系统
 
-Docker 用“分层 + CoW”的思路来实现镜像与容器层叠加，但具体后端并不完全相同。`overlay2`、`aufs` 这类后端属于联合文件系统；`btrfs`、`zfs` 更接近具备快照/克隆能力的 CoW 文件系统；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
+Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载。传统的实现方式常见于 `overlay2`、`aufs`、`btrfs`、`zfs` 等存储驱动；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
 
 > **版本背景**：Docker Engine 29.0（发布于 2024 年 2 月）是一个重要版本分界点，引入了 containerd image store 作为默认镜像存储后端。这对镜像管理、OCI 合规性和供应链安全都有深远影响。如果你的 Docker 版本低于 29.0，镜像存储仍使用传统的 classic store 路径。
 
-虽然底层实现细节不同，但它们都遵循“下层只读、上层记录差异”的总体模型；因此，无论你看到的是 `overlay2`、`zfs` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的核心思想都是一样重要的。
+虽然底层实现细节不同，但它们都遵循上述的 **分层 + CoW** 模型；因此，无论你看到的是 `overlay2` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的方式都是一样重要的。
 
 > 想要深入了解 Overlay2 等文件系统的具体实现原理，包括 WorkDir、UpperDir、LowerDir 等底层细节，请阅读 **[第十二章 底层实现](../12_implementation/README.md)** 中的 **[联合文件系统](../12_implementation/12.4_ufs.md)** 章节。