Overlay 文件系统的冲突处理机制
核心原则
- OverlayFS 通过“层叠合并 + 优先级”解决同名文件冲突：多个目录按层叠顺序合并为统一视图，遇到同一路径的文件时，上层（upperdir）优先于下层（lowerdir）；所有修改发生在可写层，底层只读层保持不变。删除文件不会抹掉底层内容，而是在可写层写入一个“whiteout”标记来表示“已删除”。合并结果通过挂载点 merged 访问。示例挂载：mount -t overlay overlay -o lowerdir=lower1:lower2,upperdir=upper,workdir=work merged。以上机制是容器镜像分层（如 Docker 的 overlay2）的基础。
冲突处理规则一览
| 场景 |
合并结果 |
说明 |
| 同名文件 |
仅保留upperdir中的文件 |
上层覆盖下层，底层镜像层不会被修改 |
| 同名目录 |
递归合并子项 |
子目录与文件按同样优先级规则处理 |
| 修改文件 |
变更写入upperdir |
底层只读层内容保持不变（写时复制） |
| 删除文件 |
在upperdir生成 whiteout |
底层文件仍存在，但 merged 视图中不可见 |
| 新增文件 |
写入upperdir |
直接出现在 merged 视图 |
| 多层 lowerdir |
按从左到右顺序查找 |
例如 lowerdir=lower1:lower2，命中 lower1 后不再检查 lower2 |
| 以上规则共同保证了“可写层定制、只读层复用”的一致合并语义。 |
|
|
在 Linux 中的实操步骤
- 规划目录与优先级：准备只读的 lowerdir（可多个，用“:”分隔，左侧优先级更高）、可写的 upperdir、以及同属同一文件系统的 workdir（用于内部工作文件）。
- 合并挂载：mount -t overlay overlay -o lowerdir=lower1:lower2,upperdir=upper,workdir=work merged，通过 merged 访问合并视图。
- 变更与验证：所有新增/修改/删除操作都应在 merged 中完成；如需还原，清空或移除 upperdir 内容并重新挂载即可恢复为底层内容。
- 注意事项：不要直接修改 upperdir；确保 workdir 与 upperdir 位于同一文件系统；如需只读合并，可将 upperdir 指向空目录（或省略以仅叠加只读层）。
在 Docker 中的实践建议
- 理解镜像层与容器层：镜像层作为 lowerdir（只读），容器可写层为 upperdir，merged 为容器看到的统一根文件系统；同名文件以容器层为准，删除以 whiteout 标记实现。
- 避免配置冲突：将需要“覆盖”的配置放入容器可写层（如通过 Dockerfile 的 COPY/ADD 或运行时挂载），或使用 卷（volume） 持久化数据，减少与镜像层的直接覆盖。
- 故障排查要点：检查挂载选项与目录权限，确认 workdir 与 upperdir 同文件系统；通过 dmesg/journalctl 查看内核/容器运行时日志；必要时清理无用层或重建镜像层缓存。
在 Android 构建中的 overlay 配置
- 使用 overlay: true 明确覆盖意图，精确指定目标路径（dest），避免模糊匹配导致的意外覆盖。
- 通过 target 限定平台/架构作用域，或用 stubs/installable: false 控制模块是否实际安装，降低模块间路径冲突概率。
- 保持覆盖路径与被覆盖模块一致，必要时调整模块依赖与优先级顺序，确保最终合并结果符合预期。