在Linux环境下部署存储服务或数据库时，文件系统的选型直接影响I/O吞吐、运维复杂度和故障恢复效率。XFS与EXT4是当前最主流的两种选择，它们都具备日志功能与良好的稳定性，但在架构设计和适用场景上存在本质区别。理解这些差异，才能避免线上磁盘性能瓶颈。
XFS与EXT4的底层架构差异
XFS最初由SGI为大型服务器设计，其核心思想是“分配组（Allocation Group）”。每个分配组独立管理自己的inode、空闲空间与B树索引，使元数据操作可以并行化。这种结构在多核、多磁盘环境中优势明显，因为不同线程可同时操作不同分配组而无需全局锁。
EXT4则是EXT3的演进版本，采用“多块分配器”和“延时分配”策略。它将连续的块分配给文件以减少碎片，并通过日记校验提高崩溃一致性。EXT4的元数据布局相对集中，在小文件密集场景下索引效率较高，但全局锁竞争在极高并发时会成为瓶颈。
# 查看磁盘文件系统类型 blkid /dev/sdb1 # 输出示例：/dev/sdb1: UUID="..." TYPE="xfs" # 查看ext4的挂载参数 mount | grep ext4
性能表现对比
在大文件顺序读写场景中，XFS通常表现更优。其预分配机制和条带对齐能充分发挥RAID与NVMe的带宽。我们曾在单机NVMe上测试10GB文件写入，XFS比EXT4快约15%，且CPU占用更低。
对于大量小文件（如代码仓库、邮件目录），EXT4的目录索引（htree）和inode就近分配策略更有利。XFS虽支持大目录，但默认不开启项目配额时，海量文件删除会触发较长延迟。以下表格列出关键指标差异：
| 维度 | XFS | EXT4 |
|---|---|---|
| 大文件吞吐 | 高 | 中高 |
| 小文件创建 | 中 | 高 |
| 碎片整理 | 支持xfs_fsr | 支持e4defrag |
| 最大文件系统 | 8EB | 1EB |
代码示例：创建与挂载
下面演示如何格式化和挂载两种文件系统。注意mkfs参数会影响后续性能，例如XFS的su/sw对应RAID条带。
# 格式化为XFS并指定条带 mkfs.xfs -f -d su=64k,sw=4 /dev/sdb1 mount -o noatime /dev/sdb1 /data/xfs # 格式化为EXT4并关闭日志校验开销 mkfs.ext4 -F -O ^metadata_csum /dev/sdc1 mount -o noatime,data=writeback /dev/sdc1 /data/ext4
运维与故障恢复
当文件系统损坏时，XFS提供xfs_repair工具，其基于日志重放，速度极快，但在严重损坏时可能丢弃部分文件以保整体一致。EXT4使用fsck.ext4，过程较缓慢但更保守，尽量保留数据。
在线扩容方面，两者均支持growfs，但XFS不支持缩小，而EXT4可通过resize2fs缩减（需离线且风险较高）。因此若业务存在容量回退需求，EXT4更灵活。
经验法则：数据库日志、视频存储选XFS；根分区、兼容旧系统选EXT4。
如何根据业务选型
对于云计算中的云盘，主流发行版（如CentOS 7+、RHEL 8）默认XFS，因其适配大容量与高并发。若运行容器密集节点，EXT4的overlayfs兼容性略好，可减少层叠写入放大。
在边缘设备使用eMMC时，由于写入寿命有限，EXT4的discard挂载选项配合定期trim更成熟。无论选哪种，都建议挂载时加noatime减少元数据写，并监控await指标。
# 查看磁盘等待时间 iostat -x 1 | grep -E "sdb|sdc" # 若await持续大于20ms，需检查文件系统碎片或调度策略
综合来看，没有绝对优劣，只有场景匹配。理清业务I/O模型，才能用对文件系统。