On Thu, 24 May 2012 16:44:58 +0400 Sergey Urushkin <urushkin@xxxxxxxxx> wrote: > Jeff Layton писал 24.05.2012 14:31: > > On Thu, 24 May 2012 10:13:29 +0400 > > Sergey Urushkin <urushkin@xxxxxxxxx> wrote: > >> > >> And I can not see any timeout options for mount.cifs (except acl > >> timeout). > >> So, the actual questions are: 1) is there a way to avoid these hangs > >> (analog of 'intr'?) and 2) how can I reduce this unreachable-host > >> timeout > >> (analog of 'timeo'?)? Maybe there are some variables in the sources? > > > > You can try setting the echo_retries kernel module parameter to 1, > > which should cut down the wait time to 60s. In 3.4, we've removed > > that parm and it's now set to 1 always. The timeout between echo > > requests (which is how we detect whether the server is still > > responding) is not currently tunable. > > That works like a charm, 60s is much better than 5m, thanks a lot. From > documentation (for kernels before 3.4) it isn't clear what behavior this > parm changes, maybe docs should be fixed some way? Well, this parm has gone away now in recent kernels so I'm not inclined to bother with documenting it. If you'd wish to do, maybe write up a section for the manpage on the socket and reconnect behavior? > Could you explain to me why SMB_ECHO_INTERVAL is so big by default? We don't really want to spam the server with a ton of these requests. The idea is that we wait a while for a response and then check with the server to see if it's still alive before timing out the packet. Most servers will respond to most calls within this time period and it's on par with the default timeo= value for NFS over TCP. Some calls however can take a very long time (minutes) writes long past the end of the file, for instance. NTFS doesn't do sparse files so it has to zero-fill them and that can take a long time on slow storage. The echo is primarily to allow us to distinguish between servers that are just slow to respond to certain calls, and those that are truly unreachable. > Is > there any side effect of changing it to, for example, "30"? Does this > change means that every 30 secs (twice more often) client will send > special packets to the server (even in the case mounted share isn't used > by any application at the moment)? Yes, reducing that interval will make it send SMB echoes to the server more frequently. Will that have any side effects? Probably not, but I've not experimented with it. I don't see a lot of value in making this tunable since this is an error condition. > What's about my first question? Could I make ls-like applications > interruptible somehow? > Most of these sleeps are TASK_KILLABLE, so they should respond to fatal signals (SIGKILL). -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
