定位IO损耗需三层联动分析：驱动行为、挂载配置、内核I/O路径；重点排查overlay2 copy-up、元数据争用、块层堆积及page cache策略。
直接看存储驱动本身不能定位IO损耗点，必须结合驱动行为、挂载配置和内核I/O路径三层联动分析。关键不是“用什么驱动”，而是“驱动在当前文件访问模式下触发了哪些开销路径”。
第一步：确认当前驱动及运行时特征
执行 docker info | grep "Storage Driver\|Backing Filesystem" 获取基础信息。重点不只是看到 overlay2，还要注意：
- Backing Filesystem 是 ext4 还是 xfs？xfs 对大目录元数据更友好，ext4 在高并发小文件场景易出现 inode 锁争用
- 是否启用 overlay2.override_kernel_check=true？未启用时，旧内核可能禁用某些优化路径
- 检查 docker system df -v 中各镜像层的 size 和 shared size 比例——若 shared size 极低，说明写时复制（copy-up）频繁，小修改已引发大量文件复制
第二步：抓取真实IO路径中的损耗环节
容器内一次 write() 调用，可能在以下环节产生延迟：
- vfs_write → overlay2 copy-up → upperdir 写入 → page cache 回写 → block layer 提交
- 用 bpftrace -e 'kprobe:vfs_write { @start[tid] = nsecs; } kretprobe:vfs_write /@start[tid]/ { @us = hist(nsecs - @start[tid]); delete(@start[tid]); }' 统计应用层 write 延迟分布，>10ms 即需下钻
- 用 blktrace -d /dev/sda -o - | blkparse -i - 观察块层请求是否堆积在 queue 阶段（表明上层提交过快，底层处理不过来），或集中在 issue → complete 时间差大（表明磁盘响应慢）
第三步：隔离驱动特有开销项
不同驱动有不同“隐性税点”，需针对性验证：
- overlay2：重点查 upperdir 目录深度与 inode 碎片。执行 find /var/lib/docker/overlay2/*/diff -maxdepth 1 | wc -l，若单个容器 diff 目录下文件超 5 万，元数据操作延迟必然上升
- zfs：检查 zpool iostat -y 1 中是否存在 ARC miss 高、L2ARC 未命中或 sync write 占比突增——压缩+写时复制会放大日志设备压力
- btrfs：运行 btrfs filesystem usage /var/lib/docker，若 data chunk 使用率 >85% 且未开启 raid1，写放大和空间碎片将显著拖慢随机写
第四步：用 fio 模拟复现，锁定驱动层瓶颈
在容器内挂载的卷路径（非 /tmp）执行：
fio --name=test --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --runtime=30 --time_based --group_reporting --filename=/mnt/vol/testfile --sync=1
对比两个结果：
- 加 --sync=1（绕过 page cache）：若 IOPS 极低，问题在块设备或驱动元数据路径
- 不加 --sync：若 IOPS 正常但应用实际写入慢，说明是 page cache 回写策略（如 vm.dirty_ratio 设置过高）或 copy-up 阻塞了 write() 返回
