docker支持的文件系统格式

Docker 支持的文件系统格式主要涉及两个层面：

  1. 存储驱动 (Storage Driver)： 这是 Docker 的核心组件，负责管理镜像层和容器层如何在宿主机文件系统上存储、分层和联合挂载。存储驱动决定了 Docker 使用哪种联合文件系统 (Union File System) 技术。
  2. **底层文件系统 (Underlying Filesystem)**： 这是存储驱动实际读写数据的宿主机文件系统格式（如 ext4, xfs, btrfs, zfs, ntfs 等）。存储驱动需要底层文件系统的特定功能支持才能工作。

一、 Linux 上主要的存储驱动及其支持的底层文件系统

  1. **overlay2 (推荐且默认)**：

    • 技术： 基于 OverlayFS 联合文件系统。
    • 底层文件系统要求：
      • ext4 (推荐，需要启用 d_type=true 选项，现代发行版默认启用)。
      • xfs (推荐，需要启用 ftype=1 选项，RHEL/CentOS 7 及以上默认启用)。
      • btrfs (需要配置为 d_type 支持)。
      • f2fs (需要配置为 d_type 支持)。
      • aufs (仅在作为底层文件系统时支持，不推荐)。
    • 优点： 性能好，内存利用率高，兼容性好，现代内核原生支持。
    • 缺点： 对底层文件系统的 d_type/ftype 有要求（现代发行版通常满足）。

  2. **aufs (Advance Union File System, 旧版默认)**：

    • 技术： 最早的联合文件系统实现之一。
    • 底层文件系统要求： ext4, xfs 等大多数文件系统（需要内核模块支持）。
    • 优点： 成熟，在旧内核上可能是唯一选择。
    • 缺点： 性能通常不如 overlay2，内核主线未包含，需要额外模块（Debian/Ubuntu 通常提供，RHEL/CentOS 不提供），逐渐被淘汰。

  3. **devicemapper (旧版 RHEL/CentOS 默认)**：

    • 技术： 利用 Linux 的设备映射器 (dm) 和瘦供给快照 (thin-provisioning snapshots)。
    • 模式：
      • loop-lvm (不推荐)： 使用稀疏文件模拟块设备，性能极差。
      • direct-lvm (推荐配置)： 使用真实的块设备（LVM），性能较好。
    • 底层文件系统要求： 本身不依赖特定文件系统格式，但 direct-lvm 模式下，块设备通常格式化为 ext4 或 xfs。
    • 优点： 在旧版 RHEL/CentOS (内核 < 3.10 或未启用 OverlayFS) 上是稳定选择 (direct-lvm 模式)。
    • 缺点： 配置复杂（尤其 direct-lvm），内存消耗较高，loop-lvm 模式性能差，整体不如 overlay2 高效。

  4. **btrfs**：

    • 技术： 直接利用 Btrfs 文件系统提供的快照和子卷功能实现分层存储。
    • 底层文件系统要求： Docker 数据根目录 (/var/lib/docker) 必须位于 btrfs 文件系统上。
    • 优点： 利用原生 Btrfs 特性（快照、压缩、去重），在某些场景可能有优势。
    • 缺点： Btrfs 自身稳定性（尤其在重度写入场景）有时受争议，社区支持不如 ext4/xfs 广泛，配置和调试更复杂。

  5. **zfs**：

    • 技术： 直接利用 ZFS 文件系统提供的快照和克隆功能实现分层存储。
    • 底层文件系统要求： Docker 数据根目录 (/var/lib/docker) 必须位于 zfs 文件系统上。
    • 优点： 利用原生 ZFS 强大特性（快照、克隆、压缩、去重、数据校验、卷管理），适合大规模存储和高级需求。
    • 缺点： 内存消耗较高（ARC），配置更复杂，内核模块可能需额外安装（ZoL）。

  6. **vfs (Virtual File System)**：

    • 技术： 不进行任何联合挂载或写时复制。每次启动容器都是完整拷贝镜像文件。仅用于测试。
    • 底层文件系统要求： 任何。
    • 优点： 简单，无特殊依赖。
    • 缺点： 性能极差（无分层共享），磁盘空间消耗巨大。绝对不要在生产环境使用。

  7. **fuse-overlayfs**：

    • 技术： 在用户空间 (FUSE) 实现的 OverlayFS。无需内核 OverlayFS 模块。
    • 底层文件系统要求： 任何支持 FUSE 的文件系统（如 ext4, xfs, ntfs-3g 等）。
    • 优点： 在无法使用内核 overlay2 驱动的环境（如内核过旧、无权限加载模块、使用非 Linux 主机上的 Linux 虚拟机）提供类似 overlay2 的功能。
    • 缺点： 性能低于内核态的 overlay2。

二、 Windows 上的存储驱动

  • **windowsfilter (默认)**：
    • 技术： 利用 Windows 的 NTFS 文件系统、硬链接和差异磁盘 (VHDX) 技术实现分层和写时复制。
    • 底层文件系统要求： Docker 数据目录必须位于 NTFS 文件系统上。
    • 注意： Windows 容器和 Linux 容器（在 Windows 上通过 WSL2 运行）使用不同的底层技术。Linux 容器在 WSL2 内部运行，其文件系统由 WSL2 管理（通常是 ext4），使用的是 Linux 的存储驱动（如 overlay2）。

三、 数据卷 (Volumes) 和 绑定挂载 (Bind Mounts)

  • 这两种方式提供独立于容器生命周期的持久化存储或与主机共享目录。
  • 它们不直接使用存储驱动的联合文件系统技术。
  • 它们使用宿主机的原生文件系统格式（如 Linux 的 ext4/xfs/btrfs/zfs/ntfs-3g, Windows 的 NTFS）。
  • 性能和功能直接取决于底层宿主机的文件系统。

四、 tmpfs 挂载

  • 将目录挂载到容器的内存中。
  • 不涉及持久化的磁盘文件系统格式。

总结与推荐

  1. **Linux 首选 (绝大多数情况)**： overlay2 驱动 + ext4 或 xfs 作为底层文件系统（确保 d_type/ftype 已启用）。这是性能、稳定性、兼容性最佳组合。
  2. 旧版 RHEL/CentOS： 如果内核不支持 overlay2，使用 devicemapper 的 direct-lvm 模式 + ext4/xfs。
  3. 特殊存储需求：
    • 想利用 Btrfs 特性： btrfs 驱动 + Btrfs 文件系统。
    • 想利用 ZFS 特性： zfs 驱动 + ZFS 文件系统。
  4. 无内核 OverlayFS 支持的环境： fuse-overlayfs (性能次于 overlay2)。
  5. Windows 容器： windowsfilter 驱动 + NTFS 文件系统。
  6. **Windows 上的 Linux 容器 (WSL2)**： overlay2 (在 WSL2 虚拟机内的 ext4 文件系统上)。
  7. 数据卷/绑定挂载： 使用宿主机原生文件系统。
  8. 绝对避免： vfs 驱动（仅测试），devicemapper 的 loop-lvm 模式。

如何查看和更改 Docker 的存储驱动？

  • docker info： 查看当前存储驱动 (Storage Driver) 和文件系统 (Backing Filesystem)。
  • 配置存储驱动： 修改 Docker 守护进程配置文件 (通常是 /etc/docker/daemon.json)，添加 { "storage-driver": "overlay2" }，然后重启 Docker (sudo systemctl restart docker)。更改存储驱动会导致现有镜像/容器不可用！ 通常只在首次安装或特殊需求时配置。

选择正确的存储驱动和底层文件系统对 Docker 的性能、稳定性和磁盘利用率至关重要。overlay2 + ext4/xfs 是现代 Linux 系统的最佳实践。