Linux NFS 挂载卡住怎么查：D 状态、soft hard 与超时边界

值守运维时最容易误判的一类 Linux 故障，就是访问 NFS 共享目录卡住无响应。终端不会弹出明确报错，对应的进程一直卡着不返回，业务线程也跟着越堆越多。先别急着直接卸载挂载点或者重启服务器：从进程状态、挂载参数和服务端可达性这三处逐步排查取证，通常能快速判断是请求仍在队列中等待、中间网络路径断连，还是挂载选项本身的配置不当放大了故障影响。

先确认：卡住的是 NFS 请求还是整个主机

假设问题目录是 /mnt/teamshare。另开一个本地目录执行 pwd、date，再观察是否只有访问该挂载点的命令不返回。如果本地磁盘也普遍变慢，排查范围就不应只盯着 NFS。

先列出相关进程：

ps -eo pid,stat,wchan:32,comm,args | awk '$0 ~ / D / || $0 ~ /teamshare/'
findmnt -T /mnt/teamshare -o TARGET,SOURCE,FSTYPE,OPTIONS
cat /proc/mounts | grep ' /mnt/teamshare '

STAT 中的 D 表示不可中断睡眠，wchan 常能提示它在等待文件系统或网络 I/O。这里先记录 PID、命令和挂载选项，不要对生产进程直接发送强制终止信号；它可能正持有未完成的文件操作。

用三条证据定位等待点

挂载参数先看实际值

重点记录 hard 或 soft、timeo、retrans、NFS 版本以及是否启用了 bg 等选项。配置文件里的旧记录不一定等于当前挂载实例，findmnt 的输出才是现场。

客户端网络只验证可达性，不代替 NFS 读写测试

ip route get 10.20.30.40
ss -tan | grep -E ':(2049|111)'
timeout 3 bash -c 'printf "" > /dev/tcp/10.20.30.40/2049' 2>/dev/null; echo $?

端口能连通，只能说明一层网络路径存在；RPC、导出权限和文件操作仍可能失败。若路由已断、网卡重连或服务端正在维护，先把时间线写进故障记录，再决定是否切换流量。

把服务端和客户端时间线对齐

客户端可检查内核日志与 NFS 相关提示：

journalctl -k --since '-15 min' | grep -iE 'nfs|rpc|not responding|server ok'
stat /mnt/teamshare/.healthcheck 2>/tmp/nfs-stat.err

如果日志出现服务端无响应，随后又出现恢复提示，说明请求可能在等待窗口内排队；如果只有单个文件操作失败，则还要考虑导出文件夹、权限或文件本身，而不是直接扩大超时。

hard 和 soft 怎么选：先看数据风险

hard 的核心语义是请求持续重试，适合不能悄悄返回半截结果的文件操作，但服务端长时间不可达时，调用线程可能一直处于等待状态。soft 会在重试达到边界后把错误返回给应用，表面上更快，却可能让应用把一次不完整的远程文件操作当成普通失败处理。

对备份、构建缓存、只读素材这类可重试场景，可以在隔离环境评估软超时；订单、账单、上传落盘等数据路径，不应只为了避免 D 状态就改成 soft。如果确实需要设置边界，先在测试挂载上缩短 timeo 和 retrans，观察应用是否正确处理错误，再进入生产变更。

恢复后这样验收，避免“目录能打开”假象

1. 确认服务端路径和客户端网络已经稳定，不只看一次端口探测。
2. 在挂载点读取一个已知小文件，记录耗时和校验值。
3. 在允许写入的测试目录创建、读取、删除一个带时间戳的小文件。
4. 复查之前处于 D 状态的 PID、应用错误日志和请求延迟，确认等待线程开始收敛。

test -r /mnt/teamshare/.healthcheck
test_file="/mnt/teamshare/.probe-$(date +%s)"
printf 'nfs-probe\n' > "$test_file" && cat "$test_file" && rm -f "$test_file"
ps -eo stat,wchan:24,comm,args | grep ' D ' | grep -E 'nfs|teamshare' || true

如果写入测试不适用，就只做只读校验，并把“未验证写路径”明确留在变更记录里。真正的恢复标准是请求、进程和业务结果都回到正常，而不是某条命令偶然返回。

常见问题：NFS 卡住时的几个判断

看到 D 状态就重启机器，行不行？

不建议作为第一步。先保存进程列表、挂载参数和内核日志；重启会丢掉现场，也可能让未完成的远程文件操作更难复盘。

把 NFS 改成 soft 就能解决卡顿吗？

不能。它只是改变超时后的错误返回方式，应用是否能安全处理这个错误才是关键。

端口 2049 能连通就代表文件服务正常吗？

不代表。还需要核对 RPC、导出路径、权限和实际文件操作；端口探测只覆盖网络连通性的一部分。

把一次排查收敛成变更清单

下次遇到 NFS 目录卡住，可以按“进程状态 → 实际挂载参数 → 网络与服务端时间线 → 小范围读写验收”的顺序取证。数据路径优先保留可解释的 hard 语义，任何 soft 调整都应先在测试环境证明应用能识别并处理超时错误。