Linux ext4 与 xfs 性能对比

ext4适合强持久化场景（如金融日志），xfs适合高吞吐场景（如监控录像）；ext4 inode静态分配易耗尽，xfs动态分配但小文件过多时readdir可能更慢；ext4磁盘检查更灵活，xfs需确保ftype=1支持容器运行。

大文件写入卡顿？看日志模式和延迟分配怎么拉扯

ext4 默认 ordered 日志模式，写 GB 级日志或视频分片时，会强制等数据落盘才提交元数据，高并发下 write() 返回慢、latency 飙升；xfs 默认启用延迟分配（delayed allocation），先攒着未分配块，到 close() 或脏页回写时才真正找空闲空间，吞吐高但崩溃可能丢掉几秒未刷盘的数据。

• 金融类流水、审计日志等要求单次写强持久化：用 ext4 + mount -o data=journal，接受约 30% 性能代价
• 监控录像、CDN 分片上传、大数据 etl：优先选 xfs，挂载时确认 barrier=1（现代内核默认开）
• 千万别在 xfs 上高频调用 sync()——它是全文件系统级阻塞操作，而 ext4 支持对单个文件精准 fsync()

小文件爆炸式增长后 df -i 报满？inode 分配机制决定能不能救

ext4 的 inode 是格式化时静态分配的，由 tune2fs -l /dev/sdX 查看 Inode count 和 Free inodes 差值，一旦耗尽，touch 新文件直接报 No space left on device，且无法在线扩容；xfs 动态分配 inode，理论上无上限，但每个 inode 占内存多，且小文件密集时 xfs_db -r -c "freesp -d" 显示的空闲空间常虚高。

• 部署千万级小文件（如容器镜像层、CI 缓存目录）：必须用 xfs，且 mkfs.xfs -n size=64k 加大命名空间，压平目录 B+ 树深度
• 已用 ext4 且 df -i 接近 100%：备份 → 重新 mkfs.ext4 -i 4096（调小 bytes per inode）→ 恢复，没有中间方案
• 别迷信 “xfs 小文件快”：单目录超 10 万文件又没做 hash 分片，readdir() 反而比 ext4 的 HTree 慢

磁盘异常掉电后恢复要多久？e2fsck 和 xfs_repair 的实操差异

e2fsck 支持只读检查（-n）、跳过特定块组（-b）、预览修复项，甚至能在只读挂载下跑诊断；xfs_repair 必须卸载，且 -n 模式不校验实时日志内容，容易误判——比如日志头损坏但 -n 显示“OK”，真跑却失败。

• 云主机热迁移失败、容器节点反复重启等需秒级判断磁盘状态的场景：ext4 更稳妥
• 用 xfs 的话，日常巡检改用 xfs_db -r -c "check" /dev/sdX（只读 AG 结构校验），它比 xfs_repair -n 更可靠
• 所有 xfs 分区务必在 mkfs.xfs 时指定 -l logbsize=256k，否则日志损坏时 xfs_repair 极易因缓冲区溢出崩溃

容器运行时报 readdir 性能骤降？ftype=1 不是可选项而是硬门槛

docker、podman 在 xfs 上依赖 d_type 字段识别目录项类型（file/dir/symlink），若格式化时没开 ftype=1，readdir() 会退化为逐个 stat()，百万级镜像层加载时延飙升数倍；ext4 默认支持 d_type，无需额外配置。

• 新建 xfs 容器存储盘：必须 mkfs.xfs -n ftype=1 /dev/sdX
• 已存在的 xfs 盘无法在线开启 ftype，只能重建
• 验证是否生效：xfs_info /mount/point | grep ftype，输出 ftype=1 才算过关

选文件系统不是挑参数，而是看你的 workload 落在哪条线上：是写完就不管的视频流，还是每笔都得落盘的交易记录；是百万小文件堆成山，还是单目录里塞了几千万个缓存对象。这些点一旦错配，性能问题往往藏在最深的调用栈里，而不是 iostat 第一眼看到的地方。