[cifs-protocol] cifs client timeouts and hard/soft mounts

[Shirish Pargaonkar]

On Sat, Dec 4, 2010 at 5:44 AM, Jeff Layton <jlayton at samba.org> wrote:

> On Sat, 4 Dec 2010 09:13:21 +0100
> Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
>
> > On Fri, Dec 03, 2010 at 09:54:13PM -0600, Christopher R. Hertel wrote:
> > > That may seem to be in the "who cares" category, since those old
> transports
> > > are essentially dead (much more dead than NBT, or even NBF).
>  Unfortunately,
> > > the code to handle the old transports is still there in Windows, so
> there
> > > are behaviors -- things like the timeouts you're talking about and the
> weird
> > > VC=0 shutdown behvior -- that exist because of these old disused
> transports.
> >
> > VC=0, how does Windows treat this facing NAT (masquerading)
> > networks? I've done tests in the past where Windows killed
> > valid connections from behind a NAT box when a new client
> > came in.
> >
> > Volker
>
> It seems like the best way to deal with this on the server side with
> direct hosted TCP would be to treat VC=0 like any other VC number
> (MS-CIFS says that this is allowed).
>
> Ideally any new connection event from a host however should make the
> server check the validity of any other connection from the same host.
> That way you could release resources held by dead connections in case
> the new one is a reconnect and needs to reclaim state.
>
> The question is how to check that validity. Unfortunately, the best you
> can probably do is rely on TCP keepalives.
>
> --
> Jeff Layton <jlayton at samba.org>
>  --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


Is SMB Echo command the only way to determine whether to reconnect or not?
The assumption here is SMB server is unresponsive.
There could be other circumstances on the server box (or even client box)
that are
slowing down the SMB server responses such as slow network, slow network
stack,
memory pressure etc.
So server could be fine all along and yet client would ask for reconnection!