XFS元数据损坏时应先卸载再修复，严禁挂载状态下操作；用xfs_repair -n预检问题，确认后再执行修复；主超级块损坏可尝试备份位置修复，日志问题才考虑-L清空，修复后须验证再挂载。
遇到XFS元数据损坏，别急着重装系统。xfs_repair不是万能钥匙，但用对了，就能把“认不出自己硬盘”的文件系统拉回来。关键在顺序、参数和判断——修错一步，可能从损坏变成丢数据。
必须先卸载，否则直接失败
这是硬性前提，不是建议。xfs_repair拒绝操作已挂载的设备，报错通常是“device is busy”或“filesystem is mounted”。强行跳过只会中断执行，毫无意义。
- 用 df -hT 或 lsblk -f 确认目标分区（如 /dev/sdb1）是否挂载、类型是否为 xfs
- 若已挂载，执行 sudo umount /dev/sdb1
- 提示 busy 时，用 lsof +D /mount/point 或 fuser -vm /mount/point 查占用进程；必要时 fuser -km /mount/point 强制释放
- 实在卸不掉？可先尝试只读重挂：sudo mount -o remount,ro /dev/sdb1 /mnt，再 umount /mnt
先用 -n 扫描，看清再动手
xfs_repair -n /dev/sdb1 是安全检查的第一步。它不写入任何修改，只报告问题和拟执行的操作，速度快、零风险。
- 输出为空 → 文件系统一致，无需修复
- 输出显示 phase 4 或 phase 5 的修复动作（如 rebuild AGI、reset log、discard inode）→ 说明真有损坏，且能预判修复影响范围
- 看到 “would reset superblock” 或 “would recreate root directory” 这类高危提示？暂停，优先备份关键数据再决定是否继续
主超级块坏了怎么办
报错 AG 0: SB not found 或 cannot read superblock，说明主超级块不可读。XFS 在固定扇区位置存有多个备份，可手动指定入口点。
- 先试常见备份地址：xfs_repair -o bbs=65536 /dev/sdb1（单位：扇区，512字节/扇区）
- 其他常用位置还有 262144、1048576；不确定时，运行 mkfs.xfs -n /dev/sdb1（加 -n 不格式化），它会列出所有已知备份超级块偏移
- -o bbs= 只是换起点扫描，并不清日志，也不丢数据，比 -L 安全得多
日志卡死才考虑 -L，不是“强力修复”
xfs_repair -L /dev/sdb1 的本质是清空日志（log zeroing），跳过崩溃恢复阶段。它解决的是日志自身损坏导致修复阻塞的问题，不是“修得更彻底”。
- 仅在常规修复反复失败、且确认无重要未同步操作（如刚创建但没 sync 的文件）时使用
- 执行后，最后一次 sync 之后的所有元数据变更（新建/删除/重命名等）大概率丢失
- 不要把它当作默认选项，更不能用于日常维护
不复杂但容易忽略：修复完成后，务必再跑一次 xfs_repair -n 验证；然后只读挂载测试能否列出目录、读取关键文件；确认无误再读写挂载。整个过程，核心就三点：卸干净、看清楚、动谨慎。
