xfs_repair 是什么
XFS 是日志型文件系统，正常崩溃后靠日志回放自动恢复一致性。一旦元数据出现回放无法修正的损坏，就需要 xfs_repair 做离线检查与修复。要注意 XFS 没有通用的 fsck 实现：/sbin/fsck.xfs 实际上不做任何检查，真正的工具就是 xfs_repair，所以「开机自动 fsck」在这类文件系统上并不成立。
基本信息
| 适用平台 | Linux（xfsprogs 包，RHEL/CentOS 系默认安装） |
|---|---|
| 命令语法 | xfs_repair [选项] 设备 |
| 常用选项 | -n 只检查不修改（预检） -v 详细输出 -L 清空日志（高风险） |
| 关键前提 | 设备必须未挂载；根文件系统需要进救援环境或在 initramfs 中操作 |
| 耗时与内存 | 按文件系统规模增长，大容量盘需要预留充足内存与时间 |
典型使用场景
- 挂载报 structure needs cleaning：说明日志无法回放或元数据损坏，需要离线修复
- 异常断电后只读挂载：先 umount 再 xfs_repair 检查
- 上线前预检：新盘或迁移过来的盘用 -n 跑一遍，确认没有遗留问题
- 扩容问题排查：xfs_growfs 失败时先确认底层元数据是否健康
- 怀疑硬件故障：修复前先看 dmesg 与 smartctl，坏盘上修完还会再坏
标准流程
标准流程
umount /data # 1. 必须卸载，挂载状态下无法修复
xfs_repair -n /dev/sdb1 # 2. 只读预检，报告问题而不改动
xfs_repair -v /dev/sdb1 # 3. 正式修复，输出各阶段进度
xfs_repair -L /dev/sdb1 # 4. 仅当日志损坏无法回放时清空日志
mount /data && dmesg | tail -5 # 5. 挂回并确认没有新的报错阶段输出读法
| 输出与阶段 | 含义 | 是否正常 |
|---|---|---|
| Phase 1 到 7 | 依次检查 inode、目录、路径、链接计数与块映射 | 全部完成且无 found 提示为正常 |
| would have been fixed | 预检模式下发现但未修复的问题 | 需要去掉 -n 再做正式修复 |
| log is dirty 或 inconsistent | 日志脏或与元数据不一致 | 先尝试回放；回放失败才考虑 -L |
| found N inodes with problems | 异常 inode 数量 | 数量大说明损坏面广，先备份再修 |
| Memory usage | 本次修复占用的内存 | 内存不足会中止，需换更大内存的机器 |
-L 会丢弃未回放的事务日志，可能造成数据丢失；只在日志损坏导致无法挂载时使用，并且事先尽力备份。执行前确认没有其他进程（如备份任务）正在访问该设备。
XFS 只能扩容不能缩小，扩容用 xfs_growfs 且支持在线执行；修复则必须离线。两者的前提与风险完全不同，别把「扩容失败」当成「需要 -L」。