核心是让 overlay2 运行在高效模式：需确保 d_type 支持（ext4 挂载加 dtype）、daemon.json 配置 overlay2.override_kernel_check 和 overlay2.size、高频 IO 用 volume 隔离并启用 noatime/nobarrier、宿主机层设置合适 IO 调度器及 blkio 限速。
核心不是换驱动，而是让 overlay2 真正跑在高效模式下——关键在于 d_type 支持、卷隔离和宿主机协同调优。
确认 overlay2 是否真正启用 dtype 支持
overlay2 默认不等于高性能。若底层文件系统（尤其是 ext4）未开启 dtype，它会自动降级为低效模式，I/O 延迟可能翻倍。
- 运行 docker info | grep -E "(Storage Driver|Supports d_type)"，确保显示 Storage Driver: overlay2 且 Supports d_type: true
- 执行 findmnt -t overlay，检查 /var/lib/docker 对应挂载项是否含 dtype 字样；若无，说明未生效
- 若用 ext4，需编辑 /etc/fstab，在对应行末尾添加 dtype（如：
/dev/sdb1 /var/lib/docker ext4 defaults,discard,dtype 0 0），再执行 sudo mount -o remount,dtype /var/lib/docker
合理配置 daemon.json 启用内核级优化
仅设 "storage-driver": "overlay2" 远不够，必须配合两项关键参数才能释放并发元数据性能。
- 在 /etc/docker/daemon.json 中加入：
"overlay2.override_kernel_check": true—— 绕过旧内核（4.15+）的兼容性拦截，实测提升小文件操作吞吐 -
"overlay2.size": "100G"—— 为每层预分配上限，避免高频写入时动态扩层导致 I/O 碎片 - 修改后执行 sudo systemctl restart docker，再用 docker info 核对 Storage Options 是否已加载新配置
用 volume 隔离高频 IO 负载路径
日志、缓存、数据库数据等高写入场景，绝不能放在联合文件系统层里——它们会污染镜像层，拖慢整个存储栈。
- 创建专用卷并启用优化选项：
docker volume create --opt o=noatime --opt o=nobarrier appdata
（noatime 省去访问时间更新，nobarrier 在 SSD 上降低写延迟） - 运行容器时显式挂载：
docker run -v appdata:/var/lib/mysql mysql:8 - 避免使用
-v /host/path:/container/path绑定挂载——它绕过 overlay2 优化，且受主机文件系统锁制约更严重
协同宿主机做 IO 层级调度与限速
当多个容器争抢同一块物理盘时，单靠存储驱动已无法保障响应稳定性，需从设备层介入。
- 查看当前调度器：cat /sys/block/sda/queue/scheduler
SSD 推荐设为 none（关闭调度）或 kyber；HDD 可试 mq-deadline - 限制突发写影响：
docker run --device-write-bps /dev/sda:20mb mydb（防单个容器写满带宽） - 柔性资源分配：
docker run --blkio-weight 80 mycache（权重范围 10–100，比硬限速更适应负载波动）
