我遇到的问题是在一段时间后,间歇性地,挂载下降.它似乎没有在任何特定的设定时间或事件,我知道它消失的唯一方法是用户的抱怨他们无法上传文件(该应用程序将文件保存在Azure文件挂载上).如果我尝试cd到mount,我的控制台就会挂起..如果我尝试用df -h列出所有内容,控制台也会挂起.我能够让事情恢复正常的唯一方法是,如果我重新启动服务器,那么一切都很好.
我怀疑与Azure的文件存储的连接可能会间歇性地丢失并返回,但也许服务器只是在它再次可用时才重新安装？我有几个其他(Windows)服务器连接到相同的文件共享,到目前为止我没有遇到此问题.有没有其他人经历过这种情况,并且可能有一个配置,如果它变得不可用,我可以自动重新安装共享？
任何建议将不胜感激！
Our engineers have provided the following Feedback for you:
This error occurs with the Linux driver re-connects to a share when the client has been idle for an extended period of time. It disconnects and the client connection times out.
•Client is idle for an extended period of time. The Linux client sends ECHO commands periodically to keep the connection alive.
•The TCP connection gets disconnected for some reason (e.g. node goes for software roll out).
•The Linux client makes a new TCP connection to port 445 but sends nothing on that connection.
•After 60 seconds of idle time,SLB drops the TCP connection.
•After some time,the Linux app tries to access a file and Linux sends NEGOTIATE packet which is black-holed by SLB.
•The Linux client waits for 15 minutes for the TCP timeout.Until we get a fix for this from the Linux developers the suggested workaround is to periodically access the share.
Workaround: Keep a file in the Azure File share that you write to periodically to sustain the connection and avoid getting into an idle state. This has to be write operation such as,rewriting the created/modified date on the file,otherwise you might get cached results and your operation might not trigger the connection.
