Home

XFS 文件系统故障修复案例

1163字 预计阅读时间：5.8分钟 运维技术

XFS 是一种高性能日志文件系统，在大文件、高吞吐和服务器场景里很常见。但它一旦出问题，处理思路和 ext3 / ext4 并不完全一样，尤其不能简单套用 fsck 那套习惯。

这篇文章把常见故障按“现象、原因、处理方法”拆开，适合作为排障时的速查笔记。

使用前先注意

  • XFS 主要依赖 xfs_repair，不是传统 fsck
  • 修复前尽量先卸载文件系统
  • xfs_repair -L 会清空日志，必须知道它的代价
  • 如果底层硬盘已经有明显硬件故障，先查磁盘再修文件系统

案例 1：XFS 文件系统无法挂载（Superblock 损坏）

故障现象

mount: /dev/mapper/centos-root: can't read superblock

或

bad primary superblock - bad magic number

可能原因

  • 超级块（Superblock）损坏（通常由于磁盘损坏或突然断电导致）。
  • 文件系统元数据不一致。

修复方法

1. 使用备份超级块恢复

XFS 在格式化时会生成多个超级块备份，可以使用 xfs_repair -b 指定备份超级块修复：

xfs_repair -b 512 /dev/sdX  # 512 是常见备份位置，可用 `xfs_db` 查找

或使用 xfs_db 查找备份超级块：

xfs_db -c "sb 0" -c "p" /dev/sdX  # 查看超级块
xfs_db -c "sb 1" -c "p" /dev/sdX  # 查看备份超级块

2. 强制修复（-L 选项）

如果超级块严重损坏，可以尝试强制修复：

xfs_repair -L /dev/sdX

⚠️ 注意：-L 会清空日志，可能导致部分数据丢失。

案例 2：XFS 文件系统日志（Journal）损坏

故障现象

XFS (sdX): log mount/recovery failed: error -5
XFS (sdX): log mount failed

或

xfs_repair: cannot read log (error 117)

可能原因

  • 日志（Journal）损坏，导致文件系统无法恢复一致性状态。
  • 可能是由于突然断电或存储设备故障。

修复方法

1. 清空日志（-L 选项）

xfs_repair -L /dev/sdX

2. 重建日志

如果 xfs_repair -L 后仍无法挂载，可以尝试重建日志：

xfs_metadump /dev/sdX /tmp/xfs_metadump  # 备份元数据（可选）
xfs_admin -z /dev/sdX  # 重置日志（危险！会丢失未提交的数据）
mkfs.xfs -f /dev/sdX   # 最后手段：重新格式化（数据会丢失）

案例 3：XFS 文件系统元数据损坏（Metadata Corruption）

故障现象

XFS (sdX): Metadata corruption detected at xfs_agi_read_verify+0x5b/0x100 [xfs]
XFS (sdX): Unmount and run xfs_repair

或

xfs_repair: bad inode magic number 0x12345678

可能原因

  • 元数据（如 inode、目录结构）损坏。
  • 可能是由于磁盘坏块或软件 Bug。

修复方法

1. 使用 xfs_repair 修复

xfs_repair -v /dev/sdX

如果失败，尝试 -L：

xfs_repair -v -L /dev/sdX

2. 使用 xfs_db 手动修复

如果关键 inode 损坏，可以尝试手动修复：

xfs_db /dev/sdX
> inode <inode_number>
> write
> quit

案例 4：XFS 文件系统只读（Read-only Filesystem）

故障现象

XFS (sdX): Filesystem has been set read-only

或

mount: /dev/sdX is write-protected, mounting read-only

可能原因

  • 文件系统检测到错误，自动进入只读模式（防止进一步损坏）。
  • 可能是磁盘 I/O 错误或硬件故障。

修复方法

1. 重新挂载为读写模式

mount -o remount,rw /dev/sdX /mnt

2. 检查磁盘错误

smartctl -a /dev/sdX  # 检查磁盘健康状态
badblocks -v /dev/sdX # 检查坏块

3. 修复文件系统

umount /dev/sdX
xfs_repair -v /dev/sdX
mount /dev/sdX /mnt

案例 5：XFS 文件系统空间异常（df 和 du 不一致）

故障现象

df -h  # 显示磁盘已满
du -sh /  # 但实际文件占用空间较小

可能原因

  • 可能是某些进程占用了已删除的文件（lsof | grep deleted）。
  • 可能是 XFS 的 free inode 计数错误。

修复方法

1. 查找并清理被删除但仍占用的文件

lsof | grep deleted  # 查看哪些进程占用已删除文件
kill -9 <PID>        # 结束相关进程

2. 重建 inode 计数

xfs_fsr /dev/sdX  # 整理碎片（可能帮助恢复空间）
xfs_repair -v /dev/sdX  # 修复 inode 计数

总结：XFS 常见修复方法

故障类型修复方法
超级块损坏xfs_repair -b <backup_sb>
日志损坏xfs_repair -L
元数据损坏xfs_repair 或 xfs_db 手动修复
文件系统只读mount -o remount,rw • xfs_repair
空间异常`lsofgrep deleted、xfs_fsr、xfs_repair`

⚠️ 重要建议：

  1. 修复前先备份数据（如 xfsdump 或 dd）。
  2. 避免强制断电，XFS 对日志依赖较强。
  3. 定期检查磁盘健康（smartctl、badblocks）。

总结

XFS 的排障重点可以概括成一句话：先分清是日志问题、元数据问题，还是底层磁盘问题，再决定是否动用 xfs_repair。

如果只是照着命令强修，往往容易把原本还能保住的数据进一步破坏。真正更稳的做法是：

  1. 先判断故障类型
  2. 再确认是否已经卸载
  3. 最后选择是否使用 -L 这类高风险参数
存储