df 卡住是怎么回事
df 默认会遍历所有挂载点并调用 statfs 取用量信息，一旦某个挂载点是失去响应的网络文件系统（NFS、CIFS、FUSE、对象存储挂载），这次调用就会阻塞，df 便停在那里不动，同一终端里其他命令也可能连带卡住。更严重的是相关进程进入不可中断的 D 状态，负载均值升高但 CPU 并不忙，这是典型的存储侧失联特征。
基本信息
| 本地视图 | df -l 只统计本地文件系统，绕过网络挂载 |
|---|---|
| 列出网络挂载 | findmnt -t nfs,nfs4,cifs,fuse / mount | grep 相应类型 |
| 典型症状 | 进程 D 状态、load 升高、df 与 ls 卡住 |
| 相关参数 | NFS 的 soft/hard、timeo、retrans 决定超时行为 |
| 日志 | dmesg 里常见 nfs server not responding 一类的提示 |
典型使用场景
- 巡检脚本突然不返回：df 卡在某个网络挂载点上
- 业务进程无响应：确认是否因存储失联进入 D 状态
- 定位是哪一台存储出问题：用 findmnt 列出所有网络挂载来源
- 恢复决策：判断等存储恢复还是必须重启客户端
- 规范化：给网络挂载设定合理的超时与恢复策略
定位与规避
定位与规避
df -l # 只列本地，先拿到可用信息
findmnt -t nfs,nfs4,cifs,fuse 2>/dev/null | head
mount | grep -E 'nfs|cifs|fuse' | head # 确认挂载来源与选项
ps -eo pid,stat,wchan:20,comm | awk '$2 ~ /D/' # 找 D 状态进程
cat /proc/<pid>/stack # 看进程卡在内核哪一层
dmesg -T | grep -i -E 'nfs|cifs' | tail -5 # 存储侧失联证据现象与处置
| 现象 | 可能原因 | 处置 |
|---|---|---|
| df 长时间无输出 | 网络挂载点失联 | 改用 df -l，联系存储侧 |
| 进程处于 D 状态 | IO 等待不可中断 | 先修复存储，强杀往往无效 |
| load 高但 CPU 空闲 | 大量进程卡在 IO 等待 | 查挂载点与存储链路 |
| dmesg 报 server not responding | NFS/CIFS 服务端不可达 | 按超时策略决定等待或重挂载 |
NFS 的 soft 挂载超时会返回错误但可能造成数据不一致，hard 挂载会一直重试直到服务端恢复；生产环境的选择需要结合业务能否容忍中断来定。
强制 umount -f 在存储失联时可能造成数据损坏或残留挂载状态，网络存储故障优先联系存储侧恢复，而不是在客户端硬拆。