On Tue, 27 Nov 2012 08:58:41 -0500 "Matthew M. DeLoera" <[email protected]> wrote:
> I'm testing in an older kernel - 2.6.15-55-386. While mount sits and waits, I > see cifsoplockd and cifsnotifyd, but no cifsd. And no /proc/PID/stack for > either. When I kill mount -a, both of those cifs daemons remain running (both > sleeping). > > I then tried later 2.6.24-24-generic kernel and got same behavior. > > Either way, for the record, cifsnotifyd was already running. Once I started > mount, then cifsoplockd started. > > Now in an even newer kernel, 2.6.32-15.generic, I get much quicker timeout - > just over 30 seconds. > > I still have to work with the older kernels I mentioned, though I'm glad to > see the behavior in 32-15. And FYI, I never saw cifsd running in 32-15. > > Agreed about kill -9. It seems like cifs timeout behavior must have changed > along the way, but my kernels span about 6 years, so that doesn't surprise > me. But since I am still stuck with the older kernels I mentioned, is there > something better that I could do, or just settle for kill -9 and allow enough > time for newer kernels to timeout? Is there a way that I might be able to > detect what timeout value I might expect? > > Cheers, > - Matthew > > Strange...cifsd is the demultiplex thread that handles the receive path. It usually also handles connecting the socket, but I don't recall if that was always the case as far back as 2.6.15... In any case, I think your choices boil down to backporting patches to lower the timeouts, or somehow working around the problem in userspace. If you know that the thing won't be mountable at boot time, you can always set it up as a "noauto" mount and simply mount it by hand when you know the connection is there. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
