📚 课程目录第4章文件系统选择

4、文件系统选择：ext4、XFS、Btrfs、ZFS在不同读写场景下的优劣与调优参数

聊到存储系统，选什么文件系统往往是个绕不开的坎。我这些年经手过不下上百套存储方案，从单机磁盘阵列到分布式集群，每个项目到了磁盘规划阶段都会纠结一次。说白了，没有万能的金刚钻，只有最适合当前读写模式的螺丝刀。你想想看，一个跑数据库日志的节点，和一个存高清视频的归档节点，它们对文件系统的诉求能一样吗？这一讲我就把 ext4、XFS、Btrfs、ZFS 这几个老面孔拿出来，结合实战场景给你捋清楚。

核心特性对比：一张表看懂底牌

先别急着调参数，得先知道每个文件系统擅长什么、怕什么。我把几个关键维度列了个对比表，这也是我每次做架构评审时会拿出来参考的东西。

特性	ext4	XFS	Btrfs	ZFS
最大文件大小	16 TB（4K块）	8 EB	16 EB	16 EB
最大文件系统	1 EB	8 EB	16 EB	256 ZB
日志方式	顺序日志（默认）	延迟日志（默认）	写时复制（COW）	写时复制 + ZIL
小文件随机读写	★★★☆☆	★★☆☆☆	★★★★☆	★★★☆☆
大文件顺序读写	★★★★☆	★★★★★	★★★☆☆	★★★★★
元数据操作	★★★☆☆	★★☆☆☆	★★★★☆	★★★★☆
数据校验	无	无	可选（checksum）	强制（checksum）
快照与克隆	无（需 LVM）	无（需 LVM）	原生支持	原生支持
压缩/去重	无	无	支持（lzo/zstd）	支持（lz4/gzip）
成熟度	极高	高	中	中高（Linux 移植版）

我的经验之谈： 别只看理论跑分。曾经一个日志采集集群，我们按网上推荐上了 XFS，结果小文件并发写入时 iowait 飙到 80%。后来切回 ext4 并加了 noatime，问题直接解决。所以对比表只能帮你画框，真实场景一定要压测。

不同读写场景下的选型推荐

场景一：数据库数据目录（MySQL / PostgreSQL）

数据库的特点是什么？随机读写多，日志同步要求高。我建议优先考虑 XFS 或 ext4。XFS 的延迟日志在事务提交时能减少 fsync 压力，但如果你的磁盘是 HDD，ext4 反而更稳——因为 XFS 的元数据密集操作容易造成碎片。我遇到过一台 PostgreSQL 服务器，数据盘用 XFS，大查询时磁盘延迟从 2ms 跳到 50ms，换成 ext4 后稳定在 5ms 以下。

场景二：视频监控 / 影音存储

这种场景基本是顺序写 + 顺序读，文件个头大。我强烈推荐 XFS 或 ZFS。XFS 对大文件连续分配的效率极高，而且在线扩容非常方便。ZFS 虽然慢一点，但内置压缩和校验，能节省大量存储空间。举个例子，我之前一个 96 盘位的冷存储集群，从 ext4 迁移到 ZFS 后，实际可用空间增加了 40%（因为视频数据压缩比高）。

场景三：容器 / 虚拟机镜像

大量小文件、快照操作频繁。这时候 Btrfs 或 ZFS 的优势就出来了——它们原生支持写时复制和快照，打一个快照几乎零开销。不过要注意，Btrfs 在碎片整理这块还有点年轻，我碰到过一次 Btrfs 元数据损坏（硬盘坏道引起），恢复起来很费劲。ZFS 的 RAID-Z 和自动修复能力在这类场景下更靠谱。

场景四：高并发元数据操作（邮件服务器、代码仓库）

元数据密集的场景，ext4 的目录索引（htree）表现最好。我建议用 ext4，并且挂载时加上 dir_index（默认已开启）。XFS 在大量 mkdir/unlink 时会锁住 inode 分配组，导致并发上不去。ZFS 虽然元数据性能不错，但内存开销太大，小内存机器不推荐。

调优参数实战

选好了文件系统，还得把参数调对。下面是我在配置时最常用的几个调整点。

ext4 调优清单

# 挂载参数优化（适合数据库或随机写场景）
mount -t ext4 -o noatime,nodiratime,data=ordered,barrier=1 /dev/sda1 /data

# 关闭日志校验（如果电源稳定可以提升10%~15%写入性能）
tune2fs -O ^has_journal /dev/sda1   # 慎用！掉电会丢数据

# 保留块比例调小（避免浪费）
tune2fs -m 1 /dev/sda1

我曾犯过的错误： 有一次为了压榨性能，把 ext4 的日志关了（^has_journal），结果机房意外断电，整个文件系统需要 e2fsck 修复了 7 个小时才起来。从那以后，除了只读归档盘，我再也不敢关闭日志。

XFS 调优清单

# 格式化时指定 agcount（根据 CPU 核心数调整）
mkfs.xfs -f -d agcount=4 -l size=128m -n size=8192 /dev/sdb1

# 挂载时关闭 atime，降低日志负载
mount -t xfs -o noatime,nodiratime,logbsize=256k /dev/sdb1 /data

# 查看当前参数
xfs_info /data

Btrfs 调优清单

# 创建文件系统时开启压缩，并指定 raid 模式
mkfs.btrfs -d raid1 -m raid1 -O compress=lzo /dev/sdc1 /dev/sdd1

# 挂载时开启异步写入与自动碎片整理
mount -t btrfs -o noatime,compress=lzo,autodefrag /dev/sdc1 /data

ZFS 调优清单

# 创建池时指定 recordsize（数据库用8K，影音用1M）
zpool create -o ashift=12 tank mirror /dev/sde1 /dev/sdf1
zfs set recordsize=8K tank/data
zfs set compression=lz4 tank/data
zfs set atime=off tank/data

# 内存缓存调整（默认会占用所有空闲内存，需要限速）
echo "16777216" > /sys/module/zfs/parameters/zfs_arc_max

核心思路： 无论哪个文件系统，noatime 都是性价比最高的优化参数——减少每次读操作时对 atime 的写入，能显著降低 iowait。另外，日志/元数据参数要跟你的磁盘类型（HDD vs SSD）和 UPS 保障一起考虑，不要盲目抄网上配置。

避坑指南（我踩过的坑）

Btrfs 的 quota 组： 我曾经在一个 Btrfs 上启用了 qgroup，结果删除一个大文件后，quota 组重度碎片导致系统卡死半小时。现在我对 Btrfs 的 quota 非常谨慎，非必要不开启。
ZFS 的 ARC 内存： 默认 ZFS 会吃掉所有空闲内存做缓存。有一台 32G 内存的服务器，跑了 ZFS 后 Java 应用频繁 OOM。后来手动限制了 zfs_arc_max 到 8G 才正常。
XFS 的 inode 分配组： 高并发创建/删除文件时，XFS 的 aglock 会导致吞吐量骤降。如果你要跑类似 GitLab CI 的构建任务，建议用 ext4 或者把 XFS 的 agcount 设高（按 CPU 核心数 x2）。
ext4 的 32 位限制： 老版本 ext4 默认用 32 位块号，文件系统最大 16TB。格式化时加上 -O 64bit,metadata_csum 才能支持更大容量。

决策流程：根据场景选文件系统

下面这张图是我自己总结的，每次做新项目时都会快速过一遍。你把它当成一个 checklist 就好。

这张图从「确定场景」开始，按读写模式分流，再导向推荐的文件系统，最后统一到参数调优和压测。我每次做存储方案评审都会过一遍这个流程，能帮你快速排除不合适的选项。当然，具体参数还得配合你的硬件环境微调。

补充一点： 如果你用的是 NVMe SSD，所有文件系统的延迟差距会缩小很多。这时候更值得关注的是数据校验、压缩、快照等高级特性。比如说，ZFS 在 NVMe 上的校验开销几乎可以忽略，但换来的是数据可靠性。这个取舍，得由你的业务重要性来定。

记住，没有的好坏，只有场景适配。你在实际调参时，可以先从文档推荐的 baseline 开始，然后在测试环境用 fio 跑一遍你的业务模型。我曾经有一次在生产环境直接改了 XFS 的 logbsize，结果日志增长过快导致磁盘满，那叫一个狼狈——所以，任何参数修改，都先在测试环境验证一周。嗯，今天就先聊到这儿。