Linux 应急模式与 XFS 文件系统修复

结论：系统进入 emergency mode 且根文件系统为 XFS 损坏时，先在 rescue 环境确认损坏块，再运行 xfs_repair -L（清 log 修复）。若 repair 在 phase 阶段崩溃（assertion/段错误），说明设备 IO 本身有问题或 repair 版本不匹配，不要反复跑 repair，先换策略：尝试只读挂载、备份数据，或换内核/工具版本。

适用范围与环境

• 系统：Ubuntu（XFS 根文件系统，设备如 /dev/sdb1）
• 现象：开机进入 emergency mode（journalctl -xb 提示文件系统错误），无法正常进入 multi-user

应急模式基本流程

1. 确认状态

# 查看挂载错误
journalctl -xb | grep -i xfs
# 检查文件系统
fsck.xfs /dev/sdb1    # XFS 不支持在线 fsck，通常需要 -n 查看

2. 尝试修复

XFS 的修复工具是 xfs_repair，不是 fsck。损坏常在 journal（log）部分：

umount /dev/sdb1            # 必须卸载（或进 rescue）
xfs_repair /dev/sdb1        # 常见，可能提示需要 -L
xfs_repair -L /dev/sdb1     # 清除 log 并重建，接受丢最后未落盘写入

-L 会丢弃未完成的日志事务，适合"机器异常断电/重启导致 log 损坏"的场景；生产环境先评估可接受的数据丢失窗口。

3. 修复后挂载

mount /dev/sdb1 /mnt
# 挂载后立即备份关键数据

修复崩溃时的处理（重要）

实际排障中出现过：xfs_repair -L 进入 phase 后崩溃：

fatal error -- directory shrink failed (117)
xfs_repair: phase6.c ... Assertion `err == 2' failed

这类崩溃说明 repair 不能靠"多跑几次"解决。按以下顺序处理：

1. 停止重复 repair：重复 -L 可能扩大损坏。
2. 检查硬件/IO 层：dmesg | grep -i error、smartctl 看磁盘健康；IO 错误导致的 XFS 损坏 repair 无法自行修复。
3. 尝试只读挂载备份：mount -o ro /dev/sdb1 /mnt，能挂则 rsync/cp -a 抢救数据。
4. 换工具版本：在 rescue 环境用更新的内核与 xfsprogs（如 Ubuntu 安装盘 rescue、Live CD 挂载根系统）再跑 repair。
5. 数据抢救完成后，损坏盘按需重建文件系统（mkfs.xfs），不要强行保留坏文件系统。

验证

• 修复成功的标志：xfs_repair 正常结束、提示 XFS_REPAIR_COMPLETE，随后可正常挂载、读写关键目录
• 应急模式恢复后 systemctl default 或 reboot 应能进入 multi-user.target

边界

• 本排障属于"数据损坏 + repair 崩溃"场景，最终是否成功抢救取决于磁盘物理状态；不同版本 xfsprogs 对同一损坏的处理结果可能不同
• XFS 不提供在线 fsck，所有修复必须在文件系统未挂载时进行