UnionFS已被OverlayFS取代，因其代码停滞、并发缺陷、无内核主线支持；OverlayFS自Linux 3.18起成为标准，结构简明、原子性强、生态完善。
UnionFS 是一种支持多层目录叠加的文件系统，其核心思想是将多个目录（称为分支）按顺序“堆叠”成一个统一视图，上层修改可覆盖下层内容，而下层保持只读。它并非 Linux 内核原生文件系统，而是以可加载内核模块形式存在，曾广泛用于早期容器镜像分层（如 Docker 0.7 之前），但目前已基本被 OverlayFS 取代。
UnionFS 的技术局限与退出原因
UnionFS 最早由查尔斯·布里格斯（Charles Briggs）开发，虽概念简洁，但长期未进入 Linux 主线内核，主要受限于：
- 代码维护停滞：上游开发在 2014 年后基本停止，缺乏对新内核版本的适配和安全更新；
- 并发与锁机制不完善：在高并发场景下易出现元数据不一致或挂载失败；
- 缺乏标准化行为定义：不同实现（如 aufs、unionfs-fuse）语义不完全兼容，影响可移植性；
- 无内核主线支持：依赖第三方 patch，增加发行版维护成本和稳定性风险。
OverlayFS 成为事实标准的关键改进
自 Linux 3.18（2014 年底）起，OverlayFS 被合入主线内核，并持续迭代。相比 UnionFS，它在设计上更精简、可靠：
- 仅需两个下层目录（lowerdir）和一个上层目录（upperdir），结构清晰，避免多层嵌套复杂性；
- 所有操作原子性更强，rename、unlink 等关键路径经充分测试，适合生产级容器运行时；
- 与 VFS 层深度集成，支持 dentry 缓存优化、copy-up 延迟触发、硬链接一致性等实用特性；
- 被 containerd、Podman、Docker（1.10+）默认启用，生态支持完善。
与其他联合文件系统的横向对比
除 UnionFS 和 OverlayFS 外，还有几个同类方案，适用场景各有侧重：
- AUFS：曾是 Docker 1.0 默认存储驱动，支持多 lowerdir 和策略控制（如 whiteout 类型），但从未进入主线内核，Ubuntu 曾长期维护其 fork，现已逐步弃用；
- Btrfs subvolume + overlay：利用 Btrfs 快照能力模拟分层，写时复制（CoW）原生支持，但依赖特定文件系统，通用性弱；
- zfs clone + overlay：类似 Btrfs，适合 ZFS 环境，快照轻量且支持压缩/加密，但部署门槛高；
- stargz / nydus：非传统联合文件系统，而是基于 OCI 镜像的按需解压（lazy loading）格式，运行时通过 FUSE 或 eBPF 实现类 overlay 访问语义，大幅优化启动速度和磁盘占用。
选型建议：从需求出发，而非名称
实际部署中不应纠结“UnionFS 是否可用”，而应关注底层支撑能力和运维目标：
- 普通容器环境：优先使用内核原生 OverlayFS（推荐配置 overlay2 驱动）；
- 需要细粒度分层控制或 legacy 兼容：评估 AUFS（仅限仍维护该内核的旧发行版）；
- 追求极致镜像拉取与启动性能：考虑 stargz 或 nydus，配合 containerd 的 snapshotter 插件；
- 已有 Btrfs/ZFS 存储池：可结合子卷快照 + overlay 混合使用，兼顾快照管理与分层语义。
