0. 问题背景：120 秒的“死亡之吻”
在超融合（HCI）架构中，当存储网络发生微秒级的抖动，上层虚拟机可能感知到的是长达120s的 I/O 阻塞。
- 报错关键词：
INFO: task postmaster:2345 blocked for more than 120 seconds - 后果：数据库进程（PostgreSQL）强制挂起，XFS 文件系统元数据在内存与磁盘的非同步状态下崩溃。
1. 修复全流程：从标准操作到异常应对
阶段一：进入救援 Shell
【标准命令】：
在 GRUB 菜单按e，在linux16行末添加rd.break，按Ctrl+X启动。
【遇到的异常 1】：无法输入任何命令，或者提示文件系统只读。
- 原因：紧急模式默认挂载
/sysroot为只读。 - 极限拉扯：
mount-o remount,rw /sysroot阶段二：寻找“失踪”的逻辑卷
【标准命令】：
尝试修复根分区：xfs_repair -L /dev/mapper/centos-root。
【遇到的异常 2】：执行修复时，发现fstab中定义的/home(即报错中的dm-2) 在/dev/mapper/下彻底消失了。
- 原因：HCI 环境下的 LVM 元数据未在 initramfs 阶段自动激活。
- 极限拉扯：
# 强制激活所有逻辑卷lvm vgchange -ay# 强制重新生成设备节点（如果还看不见 dm-2）lvm vgmknodes# 此时再次 ls /dev/mapper/ 才会出现 centos-home阶段三：修复命令的“断粮”危机
【标准命令】：
修复所有分区并创建.autorelabel文件。
【遇到的异常 3】：输入touch /sysroot/.autorelabel提示-bash: touch: command not found。
- 原因：救援环境极其简陋，很多常用二进制工具未打包。
- 极限拉扯（利用 Shell 重定向特性）：
# 既然没有 touch，就用重定向“空”创建一个文件>/sysroot/.autorelabel# 检查确认ls-a /sysroot/|grep.autorelabel阶段四：突破“进度条”的死循环
【标准命令】：
退出救援模式重启。
【遇到的异常 4】：重启后系统依然卡在progress polling进度条，或者 GNOME 图形界面转圈。
- 原因：
xfs_repair -L强制清空日志后，SELinux 标签不一致导致启动被拦截。- 底层存储响应依然缓慢，无法支撑图形界面（GDM）的重型加载。
- 极限拉扯：
再次进入 GRUB，删除rhgb quiet，并添加：3 selinux=0 3：直接进 Runlevel 3（字符模式），减小 I/O 压力。selinux=0：强行拆掉权限门禁。
2. 异常与对策速查表 (Cheat Sheet)
| 遇到的异常现象 | 背后隐藏的真相 | 解决的“救命命令” |
|---|---|---|
| 修复时找不到设备路径 | LVM 卷组在紧急模式下未激活 | lvm vgchange -ay && vgmknodes |
xfs_repair提示设备忙 | 分区已被自动挂载 | umount /dev/mapper/xxx |
touch/lvs命令不存在 | Initramfs 环境路径不全 | 使用lvm lvs或重定向> 文件名 |
| 修完磁盘依然进不去系统 | SELinux 标签错乱或 GUI 卡死 | GRUB 加入3 selinux=0并删rhgb |
3. 深度优化：为什么这台机器需要特别对待？
在这台 DB 服务器的拉扯中，最核心的教训是：不能依赖系统的自动引导。
- 分区的联动性：虽然报错是
dm-0，但因为/home分区（dm-2）在同一个存储池，底层存储抖动会造成全盘元数据损坏。必须全盘修复，不能漏掉任何一个挂载点。 - HCI 的滞后性：超融合修复后，磁盘响应可能仍有长达数分钟的“预热期”。进入Runlevel 3是给系统留出喘息空间的最佳实践。
4. 下一步：从“活下来”到“跑得稳”
既然现在已经修复，你应该立即执行以下动作进行深度加固：
1. 数据库逻辑一致性体检 (PostgreSQL 专场)
物理修复（xfs_repair -L）意味着“丢掉最后几秒日志”。这对数据库是致命的：
- 命令：登录数据库执行
REINDEX DATABASE your_db;（重建索引）。 - 检查：使用
amcheck扩展检查 B-tree 索引是否断裂。
2. 内核参数永久调优
防止下次 HCI 抖动时 Linux 反应过度。
- 修改
/etc/sysctl.conf：
# 允许内核多等一会儿存储，不要轻易认为进程死锁kernel.hung_task_timeout_secs=6003. 给超融合厂商的“罪证报告”
将/var/log/messages中那段blocked for more than 120 seconds的日志截图，并告知他们：由于物理 I/O 链路响应超时，导致上层虚拟机触发了 XFS 元数据强制修复。—
