NFS 卡死怎么救
网络文件系统服务端故障后，客户端的命令可能整体挂起：查看磁盘、列目录、读写文件全无响应，相关进程进入不可中断状态，连强杀都无效。这是因为默认的硬挂载语义要求操作必须完成，内核会一直重试。排查目标是确认卡在哪个挂载点，恢复手段则取决于挂载方式与现场容忍度。
基本信息
| 典型表现 | 列目录与查磁盘命令无响应，进程处于不可中断状态 |
|---|---|
| 关键特征 | 不能被信号杀死，只能等挂载恢复或重启 |
| 预防方向 | 改用软挂载或按需挂载，并设置合理的超时与重试 |
| 恢复手段 | 强制卸载、延迟卸载，极端情况下重启客户端 |
典型使用场景
- 存储设备维护期间客户端访问共享目录的命令全部挂住
- 备份任务读网络存储时卡死，任务长时间不结束
- 排查「某台机器无法登录或登录后卡住」是否由挂载引起
- 评估现有挂载参数在链路抖动下是否稳健
- 事后复盘并调整挂载策略，避免类似故障扩大
快速定位
快速定位
ps -eo pid,stat,wchan:25,cmd | awk '$2 ~ /D/' # 找出不可中断状态的进程
mount | grep -E 'nfs|cifs' # 确认有哪些网络挂载
cat /proc/mounts | grep nfs # 看挂载参数与来源
cat /proc/PID/stack # 看内核侧卡在哪一步
dmesg | tail -n 20 | grep -i -E 'nfs|timeout' # 内核日志里的超时记录
ping -c 2 <服务端地址> # 先判断是网络还是服务端问题卸载与恢复
卸载与恢复
sudo umount -f /mnt/nfs # 强制卸载（软挂载场景通常有效）
sudo umount -l /mnt/nfs # 延迟卸载：仍有进程占用时先解除命名空间引用
sudo mount -t nfs -o soft,timeo=30,retrans=3 10.0.0.8:/data /mnt/nfs # 改为软挂载并设置超时
sudo systemctl restart local-fs.target # 让系统按配置重新处理本地文件系统挂载挂载参数对照
| 参数 | 含义 | 取舍 |
|---|---|---|
| hard（默认） | 操作必须完成，持续重试 | 数据可靠性好，但服务端失联会卡死 |
| soft | 超时后返回错误 | 避免卡死，但需应用能正确处理 IO 错误 |
| timeo | 超时时间 | 配合重试次数一起设置才有意义 |
| retrans | 重试次数 | 次数多则恢复慢，次数少则易误报失败 |
| 按需挂载 | 访问时才建立连接 | 减少空闲连接，仍需处理首次访问时的等待 |
强制卸载在硬挂载且内核无响应时也可能失败，最终的兜底手段是重启客户端；因此预防优于救火，关键业务挂载要提前评估参数。
预防与改进
- 非关键读取场景考虑使用软挂载并配合理超时
- 备份类任务访问网络存储前先探测可用性
- 对挂载点建立独立的可用性监控，而不是等业务报障
- 把存储端维护窗口与业务方同步，提前卸载或停用相关任务
- 事故后复盘挂载参数与任务设计，形成明确的整改项
处于不可中断状态的进程对信号没有反应，先解决挂载层面的问题，比反复尝试终止进程更有效。