NFS 卡住的机理
网络文件系统默认采用硬挂载方式，访问失败时会持续重试而不是返回错误。这个设计保证了数据一致性，代价是服务端或网络中断时，任何访问该挂载点的操作都会长时间挂起，连查看目录和使用空间统计都可能卡死，进而让依赖这些目录的服务整体无响应。
先判断再动手
出现卡顿后先确认挂载点是否存在、服务端是否可达、内核日志里有没有相关报错。若只是链路短暂中断，恢复后通常能自行恢复；若服务端长期不可用，就需要按流程强制卸载，并评估是否改用带回退机制的挂载参数。任何改动都应在测试环境先验证数据一致性影响。
基本信息
| 默认行为 | 硬挂载，失败时持续重试直至恢复 |
|---|---|
| 常见参数 | 超时时间、重试次数、网络就绪依赖 |
| 判断命令 | 挂载信息、服务端导出列表、内核日志 |
| 强制卸载 | 评估影响后使用，存在数据风险 |
典型使用场景
- 共用存储的服务端维护期间，客户端访问目录卡死
- 业务报文件操作超时，排查发现依赖网络存储
- 机房网络抖动后部分节点访问共享目录挂起
- 开机时因网络未就绪导致启动流程被拖住
- 评估是否改用软挂载参数以换取快速失败
判断
判断
mount | grep -E 'nfs|cifs' # 是否存在网络挂载点
showmount -e <服务端> 2>/dev/null || echo '不通或工具未安装'
ping -c3 <服务端> # 基础连通性
dmesg -T | tail -20 # 内核侧相关报错
ss -tunap | grep ':2049' | head # 与服务端的连接状态恢复与卸载
恢复与卸载
systemctl restart nfs-client.target 2>/dev/null || true
umount -f /mnt/nfs # 强制卸载，评估影响后再执行
# 长期方案：评估超时与重试参数以及网络就绪依赖，例如挂载选项
# defaults,_netdev,soft,timeo=100,retrans=2
mount -a # 复核全部挂载点状态现象与方向
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 目录访问长时间无响应 | 服务端不可达或链路中断 | 先确认服务端与链路状态 |
| 使用空间统计卡住 | 统计需遍历挂载点内容 | 先卸载再统计本机磁盘 |
| 开机启动被拖住 | 网络未就绪即尝试挂载 | 挂载项加网络就绪依赖 |
| 恢复后仍报错 | 挂载点状态残留 | 重新挂载并复核读写 |
| 部分节点正常部分卡住 | 链路或路由差异 | 对比节点网络路径 |
软挂载以错误返回替代永久等待，能避免进程挂死，但在服务端短暂抖动时可能让应用直接收到写入失败，数据一致性取舍必须在测试环境验证后再上生产。