Docker Compose 不支持配置存储驱动，该配置由 dockerd 通过 /etc/docker/daemon.json 控制；优化小文件性能应聚焦于挂载 volumes/tmpfs、调优 overlay2 及避免频繁元数据操作。

Docker Compose 本身不支持直接配置存储驱动（storage driver），比如 overlay2、btrfs 或 zfs——这是 Docker 守护进程（dockerd）层面的配置，由 /etc/docker/daemon.json 控制，与 docker-compose.yml 无关。

但你的实际需求很明确：优化小文件读写性能（常见于日志服务、微服务临时缓存、CI/CD 构建环境等）。下面分两部分说清楚怎么做：

为什么 docker-compose.yml 不能设存储驱动

Compose 是编排工具，只负责定义容器如何启动、网络怎么连、卷怎么挂载。它把最终的容器创建请求交给 Docker daemon，而 daemon 才决定用哪个 storage driver 启动容器的可写层。这个驱动在 dockerd 启动时就固定了，运行时不可变，更无法 per-compose-file 指定。

Docker Compose

使用正确的依赖处理、网络和卷管理来定义多容器应用。

下载

真正有效的优化路径

要提升小文件性能，关键不在“换驱动”，而在**减少小文件在容器层的频繁写入 + 用合适方式持久化**。以下是实操建议：

• 禁用容器层写入小文件：把日志、临时缓存、上传目录等，全部通过 volumes 或 tmpfs 显式挂载。例如：

  services:
    app:
      image: myapp
      volumes:
        - ./logs:/app/logs        # 主机目录，避开 overlay2 小文件开销
        - /dev/shm:/dev/shm       # tmpfs 内存盘，超快且无磁盘压力

• 调优 overlay2（最常用驱动）：确保内核 ≥ 4.0、xfs/ext4 格式化时启用 ftype=1（对 xfs 必须），并开启 overlay2.override_kernel_check=true（仅调试用）。这些都在 /etc/docker/daemon.json 配：

  {
    "storage-driver": "overlay2",
    "storage-opts": [
      "overlay2.override_kernel_check=true"
    ]
  }

• 小文件密集型场景改用 tmpfs 卷：适合会话缓存、构建中间产物等短暂存在数据：

  volumes:
        build-cache:
          driver: local
          driver_opts:
            type: tmpfs
            device: tmpfs
            o: size=2g,uid=1001

• 避免在容器内反复 touch/chmod 小文件：overlay2 对元数据操作（尤其是 chmod、chown）有显著开销。可通过多阶段构建把静态资源提前打包进镜像，运行时只读；或用 read_only: true + tmpfs 组合隔离可写区域。

什么时候才需要换存储驱动？

一般不用。overlay2 在主流 Linux 发行版上已足够高效。只有满足以下全部条件时才考虑：使用 ZFS/Btrfs 文件系统 + 需要快照/压缩 + 有专人维护底层存储。即便如此，也需修改 daemon.json，而非 compose 文件。

不复杂但容易忽略：性能瓶颈往往来自应用写法（如每秒生成百个 1KB 日志文件），而不是存储驱动本身。先用 docker stats 和 strace -e trace=write,openat,chmod 定位热点，再针对性优化。