First I will apologize for posting my patch here if this is not the correct
place to post a patch.
I know that smbfs is being removed, but we still use it and need it to work.
We have a patch to contribute back to the smbfs in the 2.6 kernel. I have
noticed multiply posts on this issue and we have basically patch the smbiod.c
to fix the reconnect bug in 2.6
Something we did for our patch is to reduce the timeout from 30*HZ to 10*HZ,
so you may want to change this back to 30*HZ.
This solved the issue of a smbfs mount becoming invalid due to the smbd going
down or a lost connection. smbmount listens to SIGUSR1 to reconnect. smbfs
sends this signal. In all our test it never reconnected. We patch the
smbiod_retry() to work like the old retry code in 2.4. all appears well in
our tests.
So instead of getting just smb_add_request timeout message or smb_lookup
failed. You will now see the SMB connection re-established (-5)
and smbiod_retry: successful, new pid=-815016760, generation=2.
If you see the later message, your mount will work again.
Craig
# Patch contributed by Control4 Inc.
# Created by Craig Matsuura and Tom Wheeler
# cmatsuura@control4.com and twheeler@control4.com
#
#
--- linux-2.6.21.4/fs/smbfs/request.c 2007-06-07 15:27:31.000000000 -0600
+++ linux-2.6.21.4.new/smbfs/request.c 2007-07-18 00:01:24.000000000 -0600
@@ -333,7 +333,7 @@
smbiod_wake_up();
timeleft = wait_event_interruptible_timeout(req->rq_wait,
- req->rq_flags & SMB_REQ_RECEIVED, 30*HZ);
+ req->rq_flags & SMB_REQ_RECEIVED, 10*HZ);
if (!timeleft || signal_pending(current)) {
/*
* On timeout or on interrupt we want to try and remove the
--- linux-2.6.21.4/fs/smbfs/smbiod.c 2007-06-07 15:27:31.000000000 -0600
+++ linux-2.6.21.4.new/smbfs/smbiod.c 2007-07-18 00:01:24.000000000 -0600
@@ -232,6 +232,48 @@
/* FIXME: The retried requests should perhaps get a "time boost". */
+ /*
+ CYM - Added from 2.4 kernel to wait for the retry to connect, basically
waiting for the signal sent to smbmount to remount the samba mount that was
lost.
+ */
+ /*
+ * Wait for the new connection.
+ */
+#ifdef SMB_RETRY_INTR
+ smb_unlock_server(server);
+ wait_event_interruptible_timeout(smbiod_wait, 0, 10*HZ);
+ smb_lock_server(server);
+ if (signal_pending(current))
+ printk(KERN_INFO "smb_retry: caught signal\n");
+#else
+ /*
+ * We don't want to be interrupted. For example, what if 'current'
+ * already has received a signal? sleep_on would terminate immediately
+ * and smbmount would not be able to re-establish connection.
+ *
+ * smbmount should be able to reconnect later, but it can't because
+ * it will get an -EIO on attempts to open the mountpoint!
+ *
+ * FIXME: go back to the interruptable version now that smbmount
+ * can avoid -EIO on the mountpoint when reconnecting?
+ */
+ smb_unlock_server(server);
+ wait_event_timeout(smbiod_wait, 0, 10*HZ);
+ smb_lock_server(server);
+
+ /*
+ * Check for a valid connection.
+ */
+ if (server->state == CONN_VALID) {
+ /* This should be changed to VERBOSE, except many smbfs
+ problems is with the userspace daemon not reconnecting. */
+ PARANOIA("successful, new pid=%d, generation=%d\n",
+ server->conn_pid, server->generation);
+ result = 1;
+ } else if (server->state == CONN_RETRYING) {
+ /* allow further attempts later */
+ server->state = CONN_RETRIED;
+ }
+#endif
out:
put_pid(pid);
return result;