Linux 文件系统：从 ext4 到 XFS 的选型与挂载优化

先弄清磁盘上是什么文件系统

做任何文件系统层面的优化前，先要回答一个问题：当前磁盘分区用的什么格式？三条命令就够了：

df -hT /          # 带类型查看挂载情况
lsblk -f          # 块设备与文件系统对应关系
blkid /dev/vda2   # 查看单个分区的类型、UUID、标签

• df -hT 的 Type 列直接给出文件系统类型，-h 人性化显示容量；
• lsblk -f 输出更结构化，能一眼看出整块盘的分区布局，FSTYPE 为空表示该分区还没有格式化；
• blkid 用来精确定位某个分区，UUID 在 fstab 里挂载时会用到。

下面的演示环境是一台 Ubuntu 24.04 的云主机，根分区 /dev/vda2 使用的是 ext4：

df -hT / 显示根分区为 ext4、总量 40G；lsblk -f /dev/vda 显示 vda2 带标签 cloudimg-rootfs；blkid 则给出了完整 UUID 与 PARTUUID。这些信息后续写 fstab、做 resize2fs 扩容时都会用到。

主流文件系统速览

Linux 生态里日常最常打交道的四种文件系统各有侧重：

简单记忆法：

• 拿不准就选 ext4——几乎任何发行版开箱即用，遇到问题网上资料最多；
• 文件都是几十 GB 级的大文件，或跑数据库、日志这类高并发写入，XFS 的吞吐表现通常更好，这也是 RHEL/CentOS 把 XFS 设为默认的原因；
• 需要「轻量快照、子卷隔离」这类功能才考虑 Btrfs；需要极致的存储可靠性与自愈能力再上 ZFS，但它是「吃内存大户」，小内存机器慎用。

用 mkfs 创建文件系统（零风险练手）

格式化命令会清空目标分区上的数据，直接在服务器上练手风险很大。更稳妥的做法是：先 fallocate 造一块大小固定的镜像文件，把它当「虚拟磁盘」格式化，再用 mount -o loop 挂载——过程和真实分区完全一样，但随时可以删掉重来。

umount /mnt/demo 2>/dev/null
rm -f /tmp/fs.img
fallocate -l 512M /tmp/fs.img        # 造一块 512M 的镜像文件
mkfs.ext4 -F -q -L demofs /tmp/fs.img  # 格式化为 ext4，标签 demofs
blkid /tmp/fs.img                     # 确认格式化结果
mkdir -p /mnt/demo
mount -o loop,noatime,nodev,nosuid /tmp/fs.img /mnt/demo
findmnt /mnt/demo -o SOURCE,FSTYPE,OPTIONS  # 查看实际挂载选项

整个过程要点：

• -F 强制覆盖文件里已有的旧文件系统（镜像文件被 fallocate 后并非全零）；-q 静默模式，减少输出；-L demofs 给文件系统起标签；
• blkid 确认成功后返回 TYPE="ext4"，块大小 4096；
• mount -o loop 让内核自动把镜像文件当作块设备挂载；
• 最后的 findmnt 可以看到我们指定的优化选项已经生效：rw,nosuid,nodev,noatime。

挂载选项优化：减少写盘与加固安全

上面的挂载命令里其实已经用到了三项最常见的优化，这里单独展开说明：

注意 noatime 隐含了 nodiratime，也就是目录访问时间也不更新，对 squid 缓存、网站静态资源这类「读多写少」的目录收益最明显。

如果文件系统已经在用，不想卸载重挂，可以像这样动态调整：

mount -o remount,noatime,nodev,nosuid /mnt/demo

要让优化永久生效，把这行写进 /etc/fstab（把 UUID 换成自己分区 blkid 的结果）：

UUID=8c6cd103-8eb8-499c-9c54-f5e5a280d823  /mnt/demo  ext4  defaults,noatime,nodev,nosuid  0  2

修改 fstab 前建议 cp /etc/fstab /etc/fstab.bak 留备份；改完先用 findmnt --verify 或 mount -a 试挂，确认无误再重启，避免进不了系统。

创建 XFS 并做性能对比

XFS 的创建流程与 ext4 几乎一致，只是格式化与查看工具不同。同样是先造镜像再挂载，最后用 dd 做一次简单的顺序写性能测试：

umount /mnt/demo 2>/dev/null
rm -f /tmp/fs.img
fallocate -l 512M /tmp/fs.img
mkfs.xfs -f -q -L demofs /tmp/fs.img
blkid /tmp/fs.img
mount -o loop,noatime,nodev,nosuid /tmp/fs.img /mnt/demo
xfs_info /mnt/demo          # 查看 XFS 的布局信息
dd if=/dev/zero of=/mnt/demo/bench bs=1M count=256 oflag=direct

几点差异值得留意：

• XFS 要求文件系统至少 300MB，镜像太小会直接报 Filesystem must be larger than 300MB，所以这里用 512M；
• blkid 返回的 BLOCK_SIZE="512"，这是 XFS 的逻辑扇区大小，与 ext4 的 4096 不同；
• xfs_info 显示的是 XFS 的核心布局：agcount=4（4 个分配组）、crc=1（元数据校验开启）、reflink=1（支持 cp --reflink 写时复制）；
• dd 写入 256M 用了约 0.19 秒、约 1.4 GB/s，与前面 ext4 测得的约 1.3 GB/s 相当——单块盘的顺序写两者差别不大，XFS 的优势更多体现在多线程并发与大文件上。

dd 的顺序写只能做粗浅参考。生产环境做选型测试建议用 fio，分别测 4K 随机读写和 1M 顺序读写的 IOPS 与带宽。

文件系统体检与修复

文件系统用久了难免出现异常，两类工具分别管两种格式：

注意几个安全约定：

• 必须卸载后再修复：对已挂载分区执行 fsck 会报错或造成二次损坏，xfs_repair 同样要求先卸载；
• -f 强制：干净卸载过的 ext 分区默认会跳过检查，-f 强制全盘扫描，-y 自动回答 yes；
• xfs_repair 不要用 -n 之外的方式重复跑：它不保证幂等，多跑几遍可能引入新问题，跑不动就直接备份数据重建。

日常最该做的是「预防」：ext4 的日志（has_journal）和 XFS 的元数据校验（crc=1）本身就是崩溃后快速恢复的保障，只要不断电乱拔盘、磁盘没坏道，绝大多数异常都能自动恢复。

选型建议总结

最后给一套可落地的选型口诀：

• 系统盘、网站、代码、日常文件 → ext4。稳定、资料多、工具成熟，够用就是最好的。
• 视频/备份/大数据文件，多线程高并发写入，或软 RAID 大阵列 → XFS。分配组并行、在线扩容、崩溃恢复都快。
• 需要快照/子卷/压缩的小规模环境 → Btrfs（像 NAS 上放少量虚拟机镜像）。
• 几百 TB 级、极致数据安全 → ZFS（前提是内存管够）。

选型不是非此即彼——一台机器完全可以根分区用 ext4、数据分区用 XFS。只要掌握「先 df -hT 看清现状 → 镜像文件练手 → fstab 固化优化选项」这条链路，换任何文件系统都能快速上手。