必须先卸载XFS设备再运行xfs_repair，预检用-n参数，主超级块损坏时指定备份地址（如-o bbs=65536），仅日志损坏卡死才用-L清空日志，修复后须二次验证并只读挂载检查。
不能直接在挂载状态下运行 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 是唯一安全起点：它不修改任何数据，只扫描并报告拟执行的修复动作，速度快、零风险。
- 输出为空 → 文件系统一致，无需修复
- 出现 would reset superblock 或 would recreate root directory → 高危动作，暂停，优先备份关键数据
- 看到 phase 4: rebuilding AGI 或 phase 5: checking free space counts → 元数据确实损坏，且修复范围可预判
主超级块损坏时指定备份位置启动修复
报错 AG 0: SB not found 或 cannot read superblock，说明主超级块不可读。XFS 在固定扇区位置存有多个备份（单位：扇区，512 字节/扇区），不是靠猜，而是查。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 先试常见备份地址：
xfs_repair -o bbs=65536 /dev/sdb1 - 其他常用位置还有 262144、1048576；不确定时，运行
mkfs.xfs -n /dev/sdb1（加-n不格式化），它会列出所有已知备份超级块地址 -
-o bbs=只换入口点，不丢日志、不改元数据，比-L安全得多
日志损坏卡死才考虑 -L，但会丢数据
xfs_repair -L /dev/sdb1 的本质是清空日志（log zeroing），跳过崩溃恢复阶段。它解决的是日志自身损坏导致修复阻塞的问题，不是“修得更彻底”。
- 仅在
xfs_repair反复卡在 log replay 阶段，且dmesg | grep xfs明确报 log has invalid tail 时使用 - 执行后，最后一次
sync之后的所有元数据变更（新建/删除/重命名文件）大概率丢失 - 不要把它当默认选项——哪怕修复命令跑完没报错，也要立刻只读挂载验证目录结构是否完整
修复完成后，务必再运行一次 xfs_repair -n 验证；然后只读挂载：sudo mount -o ro /dev/sdb1 /mnt，检查能否列出目录、读取关键文件；确认无误后再以读写方式挂载。不复杂但容易忽略。
