修复XFS文件系统必须先卸载，否则xfs_repair直接报错；-n仅只读扫描，无参数才写入修复；主SB损坏需用-o superblock=N指定备份位置；-L强制清空日志，会丢失未提交事务。
修复 XFS 文件系统不能套用 ext4 的思路，关键在于工具定位、运行前提和操作逻辑完全不同。xfs_repair 不是 fsck 的一个选项，而是独立、专用、强约束的底层修复程序。
工具本质不同：调度员 vs 专科医生
fsck 是通用外壳命令，遇到 XFS 分区时会自动调用 xfs_repair；但 xfs_repair 本身不识别任何其他格式，只解析 XFS 元数据结构。它没有“兼容模式”，也不接受 -t 参数指定类型——执行 xfs_repair /dev/sdb1 时，若设备不是 XFS，会直接报错 “Invalid argument” 或 “not an XFS filesystem”。
必须卸载，且拒绝挂载状态下的任何检查
ext4 的 fsck/e2fsck 允许在挂载状态下做只读扫描（如 fsck -n），但 xfs_repair 连只读检查也强制要求文件系统已卸载。如果分区正在使用，命令会立即失败并提示 “device is mounted”。常见应对方式包括：
- 先用
lsof /mount/point或fuser -v /mount/point查占用进程 - 必要时执行
fuser -km /mount/point强制终止 - 确认卸载成功后再运行
xfs_repair -n /dev/sdb1
日志处理机制决定修复路径
XFS 依赖日志保证一致性，异常关机后通常无需人工干预——挂载时内核会自动重放日志。只有当日志损坏无法回放时，才需介入。此时：
-
xfs_repair -n可预览问题，但不会修复 -
xfs_repair尝试正常重建元数据 -
xfs_repair -L强制清空日志（丢失未提交事务，仅用于日志崩溃场景）
注意：-L 不是“一键修复开关”，而是高风险兜底操作，应先确认日志确实无法恢复（如错误信息含 “log has uncommitted transactions” 且反复失败）。
没有备份超级块，但可手动指定备用位置
ext4 有多个备份 superblock（可用 e2fsck -b 指定），而 XFS 的超级块虽也有多份，但不对外暴露编号。若主超级块损坏导致 xfs_repair 无法识别文件系统，需借助 xfs_db 探测：
-
xfs_db -r -c "sb 0" -c "p" /dev/sdb1查主超级块状态 -
xfs_db -r -c "sb 1" -c "p" /dev/sdb1逐个尝试其他副本 - 找到有效副本后，用
xfs_repair -o superblock=N /dev/sdb1指定修复
