xfs_repair -L 会不可逆清空日志并跳过校验，导致未提交元数据丢失、目录错乱或AG链断裂，真实数据丢失风险极高；仅在磁盘无物理故障、已完整镜像且常规修复失败时作为最后手段使用。

直接说结论：xfs_repair -L 会不可逆清空日志（log），并跳过所有一致性校验，已损坏的元数据可能被固化，真实数据丢失风险极高

这不是“修复”，而是“强行抹掉日志后硬启文件系统”。XFS 日志（log）本身不存用户数据，但记录了未落盘的元数据变更（如 inode 分配、目录项更新、extents 映射修改）。-L 强制清空后，这些未提交的操作全部丢弃——轻则目录结构错乱、文件变零字节或 ??? 名，重则整个 AG（allocation group）元数据链断裂，xfs_repair 后续连扫描都失败。

什么情况下才考虑用 xfs_repair -L

仅当满足全部以下条件时，才可视为最后手段：

• xfs_repair 不加 -L 报错卡在 phase 2（AGF/AGI 校验失败）或 phase 5（directory scan abort），且反复尝试 -n（dry-run）、-v（verbose）仍无法定位具体坏块位置
• 确认磁盘物理层无故障（smartctl -a 无 Reallocated/CURRENT_PENDING，dd if=/dev/zero of=/dev/xxx bs=1M count=100 conv=notrunc 不报 I/O error）
• 已对整块设备做完整镜像（dd if=/dev/sdX of=/backup/sdX.img bs=4M conv=noerror,sync），且镜像验证通过（sha256sum 两次比对一致）
• 业务可接受“最多恢复出部分文件内容，但目录树、文件名、时间戳、硬链接关系全不可信”

-L 和不加 -L 的关键行为差异

核心区别不在“是否修”，而在“依据什么修”：

• 不加 -L：读取 log + 扫描所有 AG，重建 inobt/bnoBT/finobt 等 B+ 树，尝试还原事务原子性；失败则停在 phase 并报具体 AG/AGNO
• 加 -L：直接跳过 log replay，强制将每个 AG 的 agf（allocation group free list）和 agi（allocation group inode）重置为“初始空状态”，再从头扫一遍 inodes —— 此时大量已被分配但未记入 agf/agi 的块会被误判为“空闲”，后续新写入直接覆盖
• 性能上 -L 快得多（省掉 log replay 和交叉验证

  

  ），但代价是放弃所有事务上下文，等同于把数据库的 binlog 全删了再 mysqldump --force

优先级抢救：先保数据，再保结构

一旦决定执行 -L，必须按此顺序操作，否则后续无法回退：

• 立刻卸载设备：umount /dev/sdX1；若无法卸载，用 lsof +D /mount/point 杀残留进程，**严禁 remount -o ro**（只读挂载仍可能触发内核自动 log replay）
• 用 xfs_db -r /dev/sdX1 进入只读调试模式，运行 sb 0 → print 确认 superblock 是否完好；再跑 agf 0 → print 看首个 AG 的自由块数是否异常为 0（典型 log 损坏征兆）
• 执行前加 -n 预检：xfs_repair -L -n /dev/sdX1，观察是否报 “would reset log” 及 “would rebuild AG headers” —— 若有，说明元数据已严重偏移，抢救成功率低于 30%
• 真正执行时加 -v 并重定向日志：xfs_repair -L -v /dev/sdX1 2>&1 | tee /var/log/xfs_repair_L_$(date +%s).log，重点盯住 “resetting log”、“rebuilding agf/agi”、“inode X is bad” 这几类输出

最易被忽略的一点：即使 -L 成功，挂载后看到的文件也未必是“最新版”。因为 XFS 的延迟分配（delayed allocation）机制下，write() 返回成功 ≠ 数据落盘，-L 清掉的 log 里很可能就包含这批 pending extents。此时用 xfs_findfile 或 photorec 直接扫设备镜像，反而比依赖挂载后的目录树更可靠。