xfs文件系统修复需先卸载设备，用xfs_repair -n预检；主超级块损坏时指定备份位置（如-o bbs=65536）启动修复；-l仅用于日志损坏且不可恢复时，会丢失最近元数据变更；修复后必须二次验证并只读挂载确认。
XFS超级块损坏不能直接修，得先用备份位置启动修复流程；元数据损坏必须卸载后操作，xfs_repair 默认不写入，-n 是安全起点，-L 是最后手段。
确认挂载状态并强制卸载
运行 xfs_repair 前设备必须未挂载，否则会报 device is busy 或 filesystem is mounted 并退出。这不是警告，是硬性拦截。
- 用
lsblk -f或df -hT查目标分区（如/dev/sdb1）是否挂载、类型是否为xfs - 已挂载就执行
sudo umount /dev/sdb1；若提示busy，用lsof +D /mount/point或fuser -vm /mount/point找进程 - 实在卸不掉？可先只读重挂：
sudo mount -o remount,ro /dev/sdb1 /mnt，再umount /mnt
用 -n 预检问题再决定是否修复
xfs_repair -n /dev/sdb1 不修改任何数据，只扫描并报告拟执行的修复动作。这是唯一能提前看到风险的操作。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 输出为空 → 文件系统一致，无需修复
- 出现
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 字节/扇区）：
65536、262144、1048576 - 先试
xfs_repair -o bbs=65536 /dev/sdb1；若失败，换下一个地址重试 - 不确定有哪些备份？运行
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 /dev/sdb1 验证；然后只读挂载（mount -o ro /dev/sdb1 /mnt），确认能列出目录、读取关键文件，再考虑读写挂载。底层存储若有坏道或 SSD 掉盘，xfs_repair 会反复失败，这时该先看 smartctl -a /dev/sdX。
