内核检测到进程在不可中断状态（D状态）阻塞超120秒，通常因底层I/O或锁等待导致；可能引发服务不可用、监控中断、资源耗尽及恢复困难，需立即通过ps和/proc//stack定位根因。
ainerd-shim）卡在挂载/卸载设备上，新 Pod 无法启动，老 Pod 无法清理；
read() 或 write() 等阻塞系统调用且目标设备无响应（如 NFS 服务器宕机、坏盘、iSCSI target 失联），整个工作线程将冻结。监控与日志链路中断
很多监控采集器（如 prometheus node_exporter、zabbix agent）依赖 /proc 文件系统读取指标。若内核因存储问题频繁触发 task blocked，/proc 下的文件读取可能变慢或失败，导致监控数据断更、告警失灵，掩盖真实问题。
系统资源逐步耗尽
虽然阻塞进程不占 CPU，但它仍持有内存、文件描述符、socket 连接等资源。若多个线程陆续卡住（例如连接同一故障存储的多个应用实例），会持续累积：
- 文件句柄耗尽，新连接被拒绝（
Too many open files）； - 内存无法释放，触发 OOM Killer 杀掉其他健康进程；
- 线程数达到 ulimit 上限，新请求无法派生线程，服务拒绝服务。
恢复困难且易误判
这类问题往往不能靠重启应用解决——因为根因在内核态（如驱动 bug、硬件故障、存储栈死锁）。强行 reboot 可能丢失未刷盘数据；而仅 kill 用户态父进程，常因子进程仍卡在 D 状态而残留。运维人员容易误以为是应用 Bug，反复重启，延误对存储、硬件或内核模块的真实排查。
不复杂但容易忽略：看到这条 dmesg 日志，应立即检查 ps aux | awk '$8 ~ /^D/ {print}' 定位卡住的进程，并结合 cat /proc/ 查看其内核调用栈，再聚焦对应设备、驱动或远端服务的状态。