超时影响的是等待方式
超时并不改变访问能否成功，而是决定失败时客户端表现成什么样：设置过短，正常抖动或切换过程也会被当成失败，应用频繁报错；设置过长，服务端真正不可用时业务会长时间无响应，连健康检查都难以判定。合理取值来自对服务端故障恢复时间的估计——例如切换通常需要数十秒，客户端的等待窗口就应该覆盖这段时间。
基本信息
| 适用平台 | Linux NFS 与 SMB/cifs 客户端、Windows SMB 客户端 |
|---|---|
| NFS 侧参数 | 超时与重试次数、硬挂载与软挂载选择 |
| SMB 侧 | 客户端网络超时与保活参数 |
| 上层影响 | 应用连接池与网关超时需一并考虑 |
| 调整依据 | 服务端故障切换与重启的实际耗时 |
各层超时与作用
| 层次 | 作用 | 调整原则 |
|---|---|---|
| 存储挂载层 | 决定重试与报错时机 | 与切换窗口匹配，避免过早放弃 |
| 传输层保活 | 探测连接是否仍有效 | 结合网络设备的老化时间设定 |
| 应用层请求 | 决定用户等待上限 | 应大于存储层的最坏等待时间 |
| 网关与代理 | 决定请求何时被截断 | 避免比存储层更早超时造成误导 |
示例与核对
示例与核对
# NFS：读写型负载使用硬挂载，给出可接受的等待窗口
mount -t nfs -o vers=4.2,hard,timeo=600,retrans=3 10.0.0.10:/data /mnt/data
# 查看实际生效的挂载参数
cat /proc/mounts | grep /mnt/data
# 内核保活相关参数（修改前确认对现有连接的影响）
sysctl net.ipv4.tcp_keepalive_time
# Windows 客户端超时相关设置建议通过组策略统一管理，具体项以官方文档为准写入型负载不要为了「快速失败」改成软挂载或极短超时：应用可能把超时错误当成写入结束，产生不完整文件。需要快速失败时，应在应用层处理重试与幂等，而不是让存储层放弃等待。
超时参数要按层统一设计：存储层等待很久而上层网关几秒就截断，用户只会看到网关报错，真实原因被掩盖；反过来，上层等得很久而存储层早已放弃，故障会被反复重试放大。设计时把每一层的最坏耗时列出来，保证顺序合理。