我们运行一个分布在多台服务器上的 Java 应用程序，其中一部分涉及共享文件的写入和读取。应用程序的这一部分目前由一组 rsync cron 作业支撑，因此将其替换为可解决高可用性问题的 EFS NFS 挂载选项非常有吸引力。
这些文件由 Tomcat 服务器编写和提供，并非关键任务，但有时我们每分钟要处理数千个此类请求。我们的基础设施是本地的，因此 EFS 是通过 VPN 设置安装的。考虑到可能出现的网络问题以及文件的非关键性质，我们决定宁愿快速失败和出错，也不愿冒着耗尽 Tomcat 线程池等待不可用 IO 的风险。
为此，我期待着蒂梅奥和重译参数山命令，目的是将这些设置得足够低，以便任何网络问题只会导致一堆 IO 错误（应用程序可以很好地处理），而不是一堆挂起的线程。我知道 AWS 建议不要放弃蒂梅奥参数低于 150（15 秒），但以下内容纯粹是为了验证参数的行为。
我的测试
我使用以下命令通过共享安装，
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,soft,timeo=50,retrans=1 MOUNT_IP:/ efs-test
在使用 AWS 安全组撤销对 fs 的访问权限之前，并测试了在尝试执行以下任一操作时，IO 错误发生的时间。ls安装的文件系统。山手册页和 AWS 文档显示，我预计访问挂载将在 10 秒后失败 - 5 秒超时并进行一次重试。
结果
ls 命令的超时如下：15s、17s、15s、10s、15s、20s、109s、15s。
ls: cannot access efs-test/: Input/output error
使用不同的超时和重试次数测试安装时，结果更加难以预测。我尝试通过安装本地 NFS 共享来复制此问题，但无法重现其不可预测的性质。我们无法将其推入生产环境，因为即使出现网络问题，也有可能出现两分钟的线程挂起。
有没有其他人遇到过这个问题，或者能看出我哪里出错了？我不明白为什么这个问题只发生在从 AWS 安装时，因为我本来希望在客户端强制执行 IO 超时。