Linux Overlay（通常指 OverlayFS，常用于容器、Live CD、Docker 镜像层等）虽然轻量、高效，但也存在一些局限性和使用注意事项：
1. 文件系统层面限制
1.1 底层（lowerdir）只读
- lowerdir 必须是只读的
- 如果底层目录被修改，可能导致数据不一致
- 多个 overlay 可以共享同一个 lowerdir，但不能写
1.2 上层（upperdir）必须可写
- upperdir 必须是真实文件系统，不能再次 overlay
- 不能把 overlay 挂载结果再作为 lower/upper 使用（嵌套 overlay 支持有限且不稳定）
1.3 不支持所有文件系统特性
- 不是所有文件系统都适合做 overlay 的底层（如 NFS、某些网络文件系统）
- 某些特性在 overlay 上失效或行为不同：
- 硬链接（hardlink）
- 文件锁（flock / lockf 部分支持）
- inode 一致性
2. 元数据与一致性问题
2.1 inode 不稳定
- 同一文件在 lower 和 upper 中 inode 不同
- 依赖 inode 的程序（如某些数据库、缓存系统）可能出问题
2.2 复制上行（copy-up）开销
- 第一次修改 lower 中的文件时，会整文件复制到 upper
- 大文件写入性能差
- 写放大明显
2.3 删除是“白障”（whiteout）
- 删除 lower 文件时，实际是创建一个 whiteout 文件
- 不会真正释放 lower 空间
- 目录删除更复杂（opaque whiteout）
3. 权限与安全限制
3.1 权限继承问题
- overlay 不会自动解决权限冲突
- 上层文件权限覆盖下层，但不合并
- root 权限通常需要（mount overlay）
3.2 SELinux / ACL 支持有限
- SELinux 标签在 overlay 上容易失效
- ACL 支持依赖底层文件系统
4. 性能局限
4.1 查找成本
- 文件查找需要逐层扫描（lower → upper）
- 层数越多，性能越差
4.2 不适合高写入负载
- 日志、数据库、频繁小文件写
- 更适合：只读基础 + 少量写
5. 容器场景下的典型问题
- 容器密度高时 upperdir 磁盘占用不可控
- 容器删除后残留 whiteout
- 跨主机迁移困难（upperdir 不能简单复制）
6. 内核与版本依赖
- overlay 行为随内核版本变化
- 老内核（< 3.18）不支持或 bug 多
- 某些特性（如 overlayfs redirect）需要较新内核
总结一句话
Overlay 适合“只读基础 + 轻量写”的场景，不适合高写入、强一致性、依赖 inode/锁/硬链接的应用。
如果你愿意，我可以：
- 对比 overlay vs btrfs/zfs
- 讲 Docker 中 overlay2 的具体限制
- 给出生产环境避坑建议
