tmpfs挂载不规避unionfs写时复制，而是绕过整个分层文件系统栈，使指定路径读写不经过copy-up流程；它适用于临时数据，需合理配置size与安全选项，并与metacopy、io.weight等overlay2优化策略协同使用。
tmpfs 挂载不能“规避”unionfs写时复制（cow），因为两者作用层级不同：unionfs（或更常见的 overlay2）负责容器镜像分层与运行时文件系统合并，而 tmpfs 是独立于存储驱动的内存文件系统，挂载在容器内部路径上。它的价值在于——绕过整个分层文件系统栈，让特定目录的读写完全不经过 upperdir/lowerdir 的 copy-up 流程。
用 tmpfs 替代易触发 copy-up 的临时写入路径
很多性能抖动源于应用反复写小文件（如 /tmp、/var/run、/app/cache），这些操作在 overlay2 下会高频触发 copy-up 和元数据锁争用。将这类路径改用 tmpfs，就跳过了所有分层逻辑：
- 写操作直接落在内存页缓存，无磁盘 I/O，也无跨层查找和 inode 拷贝
- 避免 open/write/stat/rename 等系统调用陷入 overlay2 的复杂路径解析
- 特别适合 session 文件、PID 文件、临时日志、JWT 缓存等生命周期短、无需持久化的数据
正确配置 tmpfs 以匹配容器负载特征
配置不当反而引发新问题（如内存溢出或权限漏洞），关键参数需对齐实际用途：
-
必须设 size=：例如
--tmpfs /tmp:rw,size=128m，防止应用无节制写入耗尽主机内存 -
敏感路径加安全选项：如
noexec,nosuid,mode=1777（用于 /tmp）、noexec,mode=700（用于密钥目录） - 避免挂载到 overlay2 高频写目录下层：比如不要把 tmpfs 挂在 /app/logs 下，再让应用往 /app/logs/access.log 写——仍可能触发父目录的 copy-up；应挂载到干净路径如 /run/secrets 或 /cache
与 overlay2 优化策略协同使用
tmpfs 不是万能替代，它只解决“局部路径”问题。真实生产环境需组合调优：
- 对非 tmpfs 路径（如应用主目录），启用
metacopy=on,redirect_dir=on减少 copy-up 开销 - 通过
--io-weight限制高写容器的 blkio 带宽，防其 copy-up 请求挤占全局 IO 资源 - 监控
/sys/fs/cgroup/docker/*/blkio.io_service_time，确认抖动是否从某容器的 upperdir 切换为 tmpfs 路径后消失
注意 tmpfs 的边界与局限
它不改变底层存储驱动行为，也不消除其他 CoW 场景：
- 容器镜像构建阶段（Dockerfile 中的 RUN）仍走 overlay2，tmpfs 对 build 无效
- 挂载点本身不共享，多个容器各自 tmpfs 独立占用内存，无法替代 volume 实现跨容器通信
- 若宿主机开启 swap，tmpfs 页面可能被换出，带来延迟波动——生产环境建议关闭 swap 或严格控 size
