Disappearing Mounts (smbfs testers wanted)

[Urban Widmark]

On Wed, 10 Jan 2001, Grant wrote:

> (1) I am using mount.smbfs so that I can mount Windows shares to perform
> crontab tasks and other various automation from the Linux side. Like
> backing up files from the Linux machine to the Windows 2000 machine.
> 
> (2) I have set the disconnection timeout on the Windows 2000 registry to
> 65535 and this did not stop the mount from being disconnected.

Hello again,

You didn't reply to on my last batch of questions. Did you work it out?

I have finally been able to repeat the problem (at least I have found _a_
problem), and perhaps also found a solution.


There is a race condition between smbmount and smbfs in the reconnect
code.

There is currently a 5 second timeout for smbmount to reconnect. That is
an awfully short time for (poorly configured/troublesome) network things,
increasing it to 30 seconds should hide the problem for a lot of cases
(when the timeout comes the current process will see an error).

The attached patch vs 2.2.18 increases the timeout to 30 seconds, and also
allows smbmount to reconnect after the timeout. The example below shows
how a mount can go "bad" and the reconnect can timeout, but how we can
recover from that if smbmount is ok.

# d /import/sputnik/export/
total 78756
drwxr-xr-x    1 puw      root          512 Jan 29 16:14 ./ 
drwxr-xr-x    3 root     root         1024 Jan 26 13:40 ../
...
# sleep 120
# d /import/sputnik/export/
ls: /import/sputnik/export/: Input/output error

	[returns after delay, reconnect timeout in smbfs]

# d /import/sputnik/export/
ls: /import/sputnik/export/: Input/output error

	[returns immediately, still no connection ...]

# d /import/sputnik/export/
total 78756
drwxr-xr-x    1 puw      root          512 Jan 29 16:14 ./
drwxr-xr-x    3 root     root         1024 Jan 26 13:40 ../
...
	[and there we go again!]

Note that I haven't actually tested _this_ patch, but I have tested a
similar patch vs 2.4.1-pre11 and it should be the same. Anyone that have 
been seeing reconnect trouble with smbfs in 2.2.18 and samba 2.0.7 should 
try this.

In my testcase samba 2.0.7 needs 7-8 seconds to make a connection, samba
2.2.0 needs less than 1 second. In this case that is the difference
between success and failure.

/Urban
-------------- next part --------------
diff -ur linux-2.2.18/fs/smbfs/proc.c linux/fs/smbfs/proc.c
--- linux-2.2.18/fs/smbfs/proc.c	Mon Dec 11 01:49:44 2000
+++ linux/fs/smbfs/proc.c	Tue Jan 30 22:43:32 2001
@@ -583,7 +583,7 @@
 	 * Wait for the new connection.
 	 */
 #ifdef SMB_RETRY_INTR
-	interruptible_sleep_on_timeout(&server->wait,  5*HZ);
+	interruptible_sleep_on_timeout(&server->wait,  30*HZ);
 	if (signal_pending(current))
 		printk(KERN_INFO "caught signal\n");
 #else
@@ -595,7 +595,7 @@
 	 * smbmount should be able to reconnect later, but it can't because
 	 * it will get an -EIO on attempts to open the mountpoint!
 	 */
-	sleep_on_timeout(&server->wait, 5*HZ);
+	sleep_on_timeout(&server->wait, 30*HZ);
 #endif
 
 	/*
@@ -611,9 +611,12 @@
 	 * Restore the original pid if we didn't get a new one.
 	 */
 out_restore:
+#if 0
+	/* Gaah! if we set this then the newconn ioctl can never
+           succeed, smbmount will see an ioctl error and terminate. */
 	if (!server->conn_pid)
 		server->conn_pid = pid;
-
+#endif
 out:
 	return result;
 }