xfs_repair报元数据损坏而xfs_db显示正常，因其检查逻辑不同：xfs_repair强制验证AG结构与跨对象引用一致性，xfs_db默认只读扫描且深度校验不足。
为什么 xfs_repair 报元数据损坏而 xfs_db 却显示正常
xfs_repair 和 xfs_db 的检查逻辑完全不同：xfs_repair 会尝试重建 AG（allocation group）结构、验证所有元数据对象的交叉引用关系（比如 inobt 指向的 inode 是否真在 inobt 中被标记为已用），并强制执行一致性修复；而 xfs_db -r 默认只做只读扫描，不校验跨结构依赖，xfs_db -c "check" 虽然能做部分一致性检查，但跳过大量深度验证（如 reverse-mapping tree、reflink 树、log replay 模拟等）。所以常见现象是：xfs_db 看起来“没报错”，但 xfs_repair 在加载 AGF/AGI/AGFL 或遍历 inobt 时发现块号冲突、空闲位图与实际 inodes 不匹配、或 CRC 校验通过但逻辑引用断裂。
抢救前必须确认的三个硬性前提
不做这些，直接跑 xfs_repair -L 可能永久丢数据：
- 确保文件系统当前未挂载（包括 read-only 挂载也不行）——
mount | grep xfs必须无输出 - 用
dd if=/dev/zero of=/path/to/backup.img bs=1M count=1024预留至少 1GB 空间用于临时日志和修复缓存，否则xfs_repair可能在中途因 tmpdir 空间不足 abort - 确认磁盘底层无硬件故障：运行
smartctl -a /dev/sdX查看Reallocated_Sector_Ct、Current_Pending_Sector是否非零；若存在，先用ddrescue克隆出镜像再操作
绕过自动修复、用 xfs_db 手动提取关键数据的实操路径
当 xfs_repair -n（dry-run）反复报类似 agi block 0x12345678 points to bad agf 或 inode 123456 has bad extent list，说明 AG 结构已断裂，此时强行 -L 清日志大概率让 root directory（inode 128）不可达。更稳妥的做法是：
