联合文件系统（如overlay2）读写大文件的主要损耗是copy-up触发的同步阻塞、i/o放大及路径查找延迟，而非带宽瓶颈；需通过多阶段构建、volume/tmpfs挂载、xfs+metacopy等规避。
联合文件系统（如 overlay2）在读写大文件时，主要损耗来自写时复制（CoW）机制和路径查找开销，不是带宽瓶颈，而是元数据与I/O调度层面的延迟。
首次写入触发整文件 copy_up
当容器首次修改一个存在于只读层（lowerdir）中的大文件（比如 500MB 的日志模板或二进制库），UnionFS 必须把整个文件从底层镜像层复制到容器的可写层（upperdir），这个过程叫 copy_up。它不是流式写入，而是同步阻塞操作：
- 复制期间，写请求被挂起，应用感知明显卡顿；
- 磁盘需完成一次完整读 + 一次完整写，I/O 放大为 2 倍；
- 若宿主机文件系统是 ext4，还可能因缺乏 reflink 支持而无法跳过物理拷贝。
多次修改导致 upperdir 空间快速膨胀
大文件被 copy_up 后，后续所有修改都落在 upperdir。但 UnionFS 不支持“原地更新”，每次覆盖写仍是全量重写（尤其对 mmap 或 seek-write 场景）：
- 一个 1GB 文件被反复追加写 10 次，upperdir 可能累积占用 10GB+（取决于写模式和 fs 缓存行为）；
- overlay2 的 upperdir 是独立目录，不共享底层块，无法自动去重；
- inode 和 block 使用率飙升，容易触发“no space left on device”错误，即使磁盘总空间充足。
读取时路径解析成本上升
虽然读大文件本身带宽不受影响，但首次 open() 仍需路径查找：
- 若镜像有 15 层，每次 open() 都要按顺序扫描 lowerdir 列表，直到命中该文件所在层；
- 内核 dentry 缓存虽能缓解，但在多容器并发访问相同大文件时，缓存争用会导致 lookup 延迟抖动；
- 特别在使用 legacy overlay（非 overlay2）或 aufs 时，层数 >10 就明显拖慢 stat/open 性能。
规避大文件 CoW 的实用办法
根本思路是让大文件绕过 UnionFS 层叠机制：
- 构建阶段：用 多阶段构建，只 COPY 编译产出的二进制，不 COPY 构建中间产物（如 node_modules、.obj）；
- 运行阶段：通过 volume 挂载或 tmpfs 存放运行时生成的大文件，完全脱离 upperdir；
- 镜像设计：用 RUN curl -o /usr/bin/app https://… && chmod +x … 替代 COPY app.tar.gz && tar -xf，避免把压缩包本身打进镜像层；
- 宿主机优化：选用支持 reflink 的 xfs 文件系统，并在 daemon.json 中启用
"storage-driver": "overlay2", "storage-opts": ["overlay2.mountopt=metacopy=on"]，部分场景可跳过 copy_up。
