本质是unionfs的copy-up机制与元数据路径查找双重压力；应切换至overlay2驱动，启用redirect_dir=on、index=on和metacopy=on，并用volume挂载大文件路径以绕过unionfs。
大文件追加写入时出现卡顿，本质是 unionfs（如旧版 aufs 或未优化的 overlay）在 copy-up 机制与元数据路径查找上的双重压力。它不是“慢”，而是设计上不适合持续追加场景——尤其当目标路径位于 unionfs 管理的镜像层内时，每次 write() 都可能触发跨层扫描、整文件复制或 inode 锁竞争。
确认是否真由 UnionFS 引发卡顿
先排除其他瓶颈，聚焦分层文件系统行为：
- 运行 docker info | grep "Storage Driver"，若显示 overlay、aufs 或 unionfs，说明仍在使用已淘汰的驱动；overlay2 是当前标准，性能差异显著
- 用 iostat -x 1 观察：若 %util 高但 await >50ms，且 r/s 远高于 w/s，大概率是路径查找或 copy-up 阻塞，而非磁盘本身慢
- 检查挂载点是否重叠：执行 mount | grep "$(docker info | awk '/Docker Root Dir/ {print $4}')" | grep -E "(upper|merged|work|volume)"，确认你的 volume 挂载路径没落在
/var/lib/docker/overlay2/xxx/merged/...下层目录中
强制绕过 UnionFS 层，直通宿主机文件系统
Volume 本意就是跳过 UnionFS，但若挂载目标与镜像层路径冲突，UnionFS 仍会干扰访问逻辑。关键在“隔离路径”和“显式传播”：
- 不要把 volume 挂到镜像中已有内容的路径（如
/var/log、/app/data），改用空路径：/mnt/vol-data或/data/shared，并在启动时用-v /host/bigfiles:/mnt/vol-data:rw - 对 bind mount，必须加传播模式：
--mount type=bind,source=/host/bigfiles,target=/mnt/vol-data,bind-propagation=rslave，避免被 UnionFS 的 mount namespace 遮蔽 - 确保宿主机目录不在
/var/lib/docker下——哪怕只是子目录，overlay2 内核模块也可能拒绝挂载或降级为只读
替换存储驱动，彻底告别 UnionFS 限制
Overlay2 不是“升级选项”，而是当前生产环境的事实标准。它对大文件追加更友好：
- 启用 redirect_dir=on 和 index=on：减少 rename 和 lookup 开销，避免每次追加都重新解析整个路径树
- 支持稀疏 copy-up：修改大文件末尾时，不会复制整块文件，只搬运变更页，大幅降低 I/O 压力
- 内核原生支持（≥4.0），无用户态模块开销，page cache 可跨容器共享，缓存命中率更高
- 切换前备份
/var/lib/docker，然后修改/etc/docker/daemon.json加入{"storage-driver": "overlay2"}，重启 dockerd
应用层配合：减少 UnionFS 干预机会
即使底层仍是 UnionFS，也能通过写法降低触发频率：
- 用 O_APPEND | O_DIRECT 打开文件：跳过 page cache，避免因缓存一致性引发的额外元数据操作
- 批量写入代替高频小写：将多次
write(fd, buf, 4KB)合并为单次write(fd, big_buf, 64MB)，减少系统调用次数和 copy-up 触发频次 - 写入前先 fallocate() 预分配空间：避免文件增长时反复扩展 inode、更新 block map，这对机械盘或低配云盘效果明显
