On Sat, 4 Dec 2010 08:06:46 -0600 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Sat, Dec 4, 2010 at 7:09 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Sat, 4 Dec 2010 06:25:07 -0600 > > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > >> On Sat, Dec 4, 2010 at 5:44 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > >> > >> > On Sat, 4 Dec 2010 09:13:21 +0100 > >> > Volker Lendecke <Volker.Lendecke@xxxxxxxxx> 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@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 > >> > > >> > >> > >> 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@xxxxxxxxx> > > > > 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@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
