The Samba-Bugzilla – Bug 10499
Current timeout strategy is not enough for unreachable shares.
Last modified: 2017-05-03 09:37:09 UTC
I'm using kernel 3.11.10 from opensuse 13.1. It says that my cifs module version is 2.01.
I have a smb share mounted to a subdir in my home directory. I use this share for some configs and files, like bashrc. Also, I have symlink to subdir inside this share. When smb server is unreachable, my system is almost useless (for my user).
I'm already using the default mount option soft that results in a timeout at about 60s. The problem is that this timeout is waited for every operation. There is no "disconnected" status for the mount-point.
The result is that, when smb server is unreachable, for every new request for files inside the smb share, it will hang for about 60s. If there is multiple operations on it, the timeout will be even more. For terminal usage that spawns multiple process, this is not ideal.
As a suggestion, the cifsVFS should keep a per-mountpoint connection state. When any operation timeouts, it should set the state to "disconnected" and every waiting request should immediately return "host disconnected" error. Every new request should also return the same "host disconnected" until this state is changed to "connected".
When a request has changed the mount-point state to "disconnected", a parallel process should try forever to reconnect to the smb server, in a ping-like operation. The state will only be changed back to "connected" when this "parallel ping" is able to reach the samba server.
Also, umount operations, when state is "disconnected", should not hung.
This would result in a much improved user experience when samba is unreachable.
This should be fixed in current design of reconnect with cifs.ko
(and we now use 'echo' to tell if share needs reconnection, and the "echo_interval" is configurable to shorter or longer than 60s if needed to check server responsiveness faster)