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

[Jeff Layton]

On Sat, 4 Dec 2010 08:06:46 -0600
Shirish Pargaonkar <shirishpargaonkar at gmail.com> wrote:

> On Sat, Dec 4, 2010 at 7:09 AM, Jeff Layton <jlayton at samba.org> wrote:
> > On Sat, 4 Dec 2010 06:25:07 -0600
> > Shirish Pargaonkar <shirishpargaonkar at gmail.com> wrote:
> >
> >> 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!
> >
> > I think it's the best mechanism that the protocol has. If we aren't
> > going to use SMB echoes to detect an unresponsive server, then what
> > would you suggest? I don't think we can make calls wait indefinitely
> > for a response without a mechanism to determine when the server is gone
> > and attempt to reestablish the connection to it.
> >
> > --
> > Jeff Layton <jlayton at samba.org>
> >
> 
> I think we should use smb echo command as a means to let users know the
> state of mount/server and let them decide.
> If smb echo times out, cifs client should just log it and stop at that and a
> very next request that receives a response (if any does) should log that server
> is responding.

Could you elaborate a bit?

What do you mean by "let them decide" -- what steps would someone take
if the server stopped responding? Aside from killing the application,
what recourse would they have?

-- 
Jeff Layton <jlayton at samba.org>