xfs在大文件顺序写入和海量小文件删除场景下性能更优，ext4默认预留5%空间影响df显示，xfs日志重放通常更快但依赖硬件配置。
ext4 和 xfs 在大文件顺序写入时性能差异明显吗
差别不大，但 xfs 通常略稳——尤其在持续多线程写入 TB 级单文件时，xfs 的分配策略更少触发延迟。ext4 默认使用 extents 模式后已大幅优化，但若未关闭 journal=ordered 或仍用 data=writeback，日志开销可能拖慢吞吐。
- 实测场景：16 线程向同一块 NVMe 盘顺序写入 100 个 50GB 文件，xfs 平均带宽高约 8%～12%，且波动更小
- 关键配置影响：ext4 启用
barrier=0（仅限断电不敏感环境）可缩小差距；xfs 必须挂载时加nobarrier才能彻底关屏障，否则仍走底层 flush - 容易踩的坑：
mkfs.ext4 -t ext4 /dev/sdb不等于启用 extents——只要内核 ≥2.6.23 且创建时不加-O ^extents，就默认开启；但老镜像重刷可能残留 legacy block mapping 配置
删除海量小文件时哪个更快
xfs 明显占优，尤其是目录项超百万后。ext4 的目录索引（dir_index）虽已普及，但删除仍需逐个更新 inode 位图和块组描述符，锁竞争剧烈；xfs 的 B+ 树目录 + 延迟回收（inode64 + allocsize=64k）让并发 unlink 更轻量。
- 典型错误现象：
rm -rf /var/log/journal在 ext4 上卡住数分钟，top显示ext4_da_write_pages占 CPU 高，而 xfs 下几乎无感知 - 使用场景适配：容器临时卷、CI 构建缓存目录这类“创建-写入-批量删”模式，优先选 xfs
- 注意兼容性：某些旧版备份工具（如早期
rsync+--delete）在 xfs 上对硬链接处理有边界 case，建议确认rsync --version≥3.1.3
df 显示容量不准，是文件系统选型问题吗
不是选型问题，是预留空间机制不同导致的表象。ext4 默认保留 5% 的空间给 root，df 统计时直接扣除；xfs 默认不预留，但 xfs_info 中的 agcount 和 agsize 会影响实际可用块计算逻辑，尤其在非对齐分区上。
- 常见错误现象：
df -h显示 ext4 分区只剩 3%，但sudo -u nobody touch /mnt/test仍成功——说明预留空间未计入用户可见容量 - 调整方法：ext4 可用
tune2fs -m 1 /dev/sdb1改为保留 1%；xfs 无法设全局预留，但可通过xfs_growfs -m调整最大 inode 数间接影响元数据开销 - 性能影响：ext4 降低
-m值后，接近满盘时碎片率上升更快；xfs 在 95%+ 使用率下，agfree减少会导致新文件分配变慢，比 ext4 更早出现延迟尖刺
系统崩溃后恢复时间谁更短
xfs 日志重放（log replay）通常更快，但前提是没启 logbsize 过大或日志设备慢；ext4 的 journal 回滚粒度更细，单事务修复可靠性略高，不过现代内核（≥5.4）+ metadata_csum 已极大收窄差距。
- 真实瓶颈常在硬件层：xfs 日志默认写到主分区（
logdev=internal），若磁盘本身响应差，xfs_repair -L（强制清日志）反而成常态；ext4 的 journal 若放在独立 SSD 上，e2fsck能跳过多数检查 - 必须做的检查：
xfs_info /mount/point | grep log确认日志位置；dumpe2fs -h /dev/sdb1 | grep "Journal"查 ext4 日志状态 - 容易被忽略的点：xfs 不支持在线 resize 缩小，崩溃后若要紧急腾空间，只能先 dump 再 mkfs；ext4 虽支持
resize2fs缩容，但要求文件系统未挂载且无未完成事务——这点两者都得靠备份兜底