1. 当CentOS虚拟机突然进入紧急救援模式时该怎么办
那天早上我正喝着咖啡准备开始工作，突然发现一台重要的CentOS测试虚拟机启动不起来了，屏幕上赫然显示着"entering emergency mode"的红色警告。作为运维老手，我知道这通常意味着文件系统出了问题，但具体该怎么处理呢？这种场景其实很常见，特别是当我们非正常关机或者磁盘出现问题时。
紧急救援模式是Linux系统的一种特殊状态，当系统检测到关键错误无法正常启动时，会自动进入这个模式。它提供了一个最小化的环境，让我们能够排查和修复问题。遇到这种情况先别慌，保持冷静才能快速定位问题。我习惯先做三件事：查看系统日志、确认错误类型、制定修复方案。
2. 第一步：使用journalctl定位XFS文件系统错误
2.1 查看完整系统日志的正确姿势
在紧急救援模式下，输入以下命令查看系统日志：
journalctl -xb这个命令会显示完整的启动日志，其中-x参数会添加解释性文字，-b表示只显示本次启动的日志。我强烈建议加上这两个参数，因为它们能提供更友好的错误说明。
当我翻到日志底部时（使用Shift+G快速跳转），发现了关键错误信息：
XFS (dm-0): Metadata corruption detected at xfs_agi_read_verify+0x8b/0xf0 [xfs] XFS (dm-0): Unmount and run xfs_repair这明确告诉我们/dev/dm-0设备上的XFS文件系统出现了元数据损坏。dm-0是设备映射器的命名，通常对应着LVM逻辑卷。在CentOS中，这往往就是根文件系统所在的位置。
2.2 理解XFS文件系统的结构特点
XFS是一种高性能的日志文件系统，它的结构包括：
- 超级块(Superblock)：记录文件系统整体信息
- 分配组(Allocation Groups)：将磁盘空间分成多个独立管理的区域
- 日志区(Journal)：记录文件系统的元数据变更
当这些关键数据结构损坏时，就会导致系统无法正常挂载分区。理解这一点很重要，因为它决定了我们后续修复策略的选择。
3. 初步修复尝试：使用xfs_repair工具
3.1 xfs_repair的基本用法
看到XFS错误后，我的第一反应是使用xfs_repair工具进行修复。这个工具专门用于修复损坏的XFS文件系统。基本命令格式如下：
xfs_repair /dev/dm-0但实际操作中，我推荐加上-v(verbose)参数查看详细过程，以及-L参数强制清空日志：
xfs_repair -v -L /dev/dm-0-L参数特别重要，它告诉工具即使日志包含未提交的变更也强制清零。这相当于给文件系统一个"重新开始"的机会。在我的案例中，这个操作确实修复了一些小问题，但重启后系统仍然进入紧急模式。
3.2 修复过程中的注意事项
执行xfs_repair时有几个关键点需要注意：
- 绝对不能在已挂载的文件系统上运行此工具
- 修复前最好先做备份（如果可能的话）
- 大型文件系统修复可能需要较长时间
- 某些严重损坏可能需要多次运行修复命令
在我的场景中，第一次修复看似成功了，但重启后问题依旧，这说明还有更深层次的问题需要解决。
4. 深入问题：解决"Device or resource busy"错误
4.1 理解错误背后的原因
当我再次尝试运行xfs_repair时，遇到了新的错误：
xfs_repair: cannot open /dev/dm-0: Device or resource busy这个错误表明目标设备正在被使用。仔细回想日志中的提示："Unmount and run xfs_repair"，我意识到自己犯了一个常见错误——没有先卸载文件系统就尝试修复。
4.2 正确处理设备映射和挂载点
这里有个关键知识点：/dev/dm-0实际上是LVM逻辑卷的映射设备。在CentOS中，它通常软链接到/dev/mapper/centos-root。要正确卸载，我们需要：
umount /dev/mapper/centos-root但有时候系统可能已经自动卸载了设备，却仍然保持设备忙状态。这时可以检查：
lsblk这个命令会显示所有块设备及其挂载状态。如果确认设备未挂载但仍然忙，可能是内核还在占用。这时可以尝试：
dmsetup remove_all这个命令会清除所有设备映射器设备，通常能解决资源占用问题。
5. 完整修复流程与实战经验分享
5.1 分步修复指南
结合我的实际经验，完整的修复流程应该是：
- 进入紧急救援模式
- 查看日志确认错误类型：
journalctl -xb - 尝试卸载相关设备：
umount /dev/mapper/centos-root - 如果卸载失败，检查占用进程：
lsof /dev/mapper/centos-root - 强制清除设备映射：
dmsetup remove_all - 执行修复命令：
xfs_repair -v -L /dev/mapper/centos-root - 检查修复结果：
xfs_check /dev/mapper/centos-root - 重启系统：
reboot
5.2 可能遇到的特殊情况处理
有时候即使按照上述步骤操作，问题仍然存在。这时候可能需要考虑：
- 使用
-n参数先进行干运行，检查文件系统损坏程度 - 对于严重损坏，可能需要使用
xfs_metadump保存元数据后重建文件系统 - 检查物理磁盘健康状况：
smartctl -a /dev/sda - 考虑从备份恢复关键数据
我在一次特别棘手的情况中，发现是磁盘物理坏道导致的反复损坏。最终不得不更换磁盘并从头重建系统。这也提醒我们定期检查磁盘健康状态的重要性。
6. 预防措施与最佳实践
6.1 如何避免XFS文件系统损坏
经过这次事件，我总结了几条预防措施：
- 避免非正常关机：这是导致文件系统损坏的最常见原因
- 定期检查文件系统：可以设置定期运行的
xfs_check任务 - 监控磁盘健康：使用smartd等工具监控磁盘SMART状态
- 合理配置日志大小：XFS日志大小影响恢复能力，对重要系统可以适当增大
- 建立备份机制：特别是对关键配置文件和数据
6.2 紧急救援模式下的实用技巧
在紧急救援模式下工作时，有几个实用技巧能提高效率：
- 使用
chroot /mnt/sysimage切换到原系统环境 - 如果网络可用，可以安装额外工具：
yum install -y strace lsof - 使用
systemctl rescue进入更完整的救援环境 - 对于复杂问题，考虑使用LiveCD启动进行修复
记住，每次修复操作前都要确认当前工作环境，避免误操作导致问题扩大。特别是在处理生产环境时，一定要谨慎再谨慎。
