overlay2是抑制容器写放大的首选驱动，需满足内核≥4.0、文件系统支持d_type=1、overlay模块已加载，并配置overlay2.xino=auto等参数以降低元数据写放大。
Compose部署中因存储驱动选型不当引发的容器写放大，本质是底层存储驱动与文件系统行为不匹配导致的重复I/O和元数据拷贝。这在devicemapper（尤其是loop-lvm）和aufs中尤为突出，而overlay2配置不当也会加剧该问题。解决核心在于驱动迁移、内核适配与挂载优化。
识别写放大的典型信号
写放大并非直接报错，而是表现为隐蔽的性能退化：
- 相同负载下磁盘I/O量明显高于预期（iostat -x 1 观察 %util 和 r_wsec/s）
- 容器内频繁执行 cp、tar 或日志轮转时，宿主机磁盘写入速率激增数倍
- docker info 响应迟缓，或 docker system df 显示镜像层大小远超实际内容
- 使用 perf record -e block:block_rq_issue 可捕获大量小块、重复的写请求
优先迁移到 overlay2 并验证基础条件
overlay2 是当前唯一能有效抑制写放大的主流驱动。但仅切换驱动不够，必须确认三项前提：
- 内核版本 ≥ 4.0（生产环境建议 ≥ 5.11），运行 uname -r 确认
- /var/lib/docker 所在文件系统支持 d_type=1：对 ext4 执行 sudo dumpe2fs -h /dev/xxx | grep -i d_type；对 xfs 则需格式化时指定 ftype=1
- 确保 overlay 已加载：cat /proc/filesystems | grep overlay 应有输出
overlay2 关键调优参数
在 /etc/docker/daemon.json 中添加以下配置，可显著降低元数据操作引发的写放大：
- "storage-opts": ["overlay2.xino=auto"]：Linux ≥ 5.15 时启用，避免 stat 竞争导致的反复 inode 查找与拷贝
- 禁用 overlay2.override_kernel_check（仅限测试）：若内核略旧但已确认 d_type 支持，可临时绕过检查，但不推荐生产使用
- 绝对避免在 /var/lib/docker/overlay2 所在分区启用配额（quota）或加密（如 eCryptfs），它们强制同步元数据更新，放大写入路径
彻底清理旧驱动残留
若原用 devicemapper 或 aufs，迁移前必须清空数据目录，否则旧层仍可能被间接引用：
- 停服务：sudo systemctl stop docker
- 备份卷数据（如需）：sudo cp -a /var/lib/docker/volumes /backup/
- 清空存储根目录：sudo rm -rf /var/lib/docker/{devicemapper,aufs,overlay2,image,containers,volumes,network}
- 重启 Docker 后，所有镜像、容器、卷将重建，确保从干净状态开始
