On Sun, 5 Dec 2010 20:16:46 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > On Sun, Dec 5, 2010 at 8:06 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > > On Sun, 5 Dec 2010 19:42:30 -0600 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > > > On Sat, Dec 4, 2010 at 2:12 AM, Volker Lendecke > > > <Volker.Lendecke@xxxxxxxxx>wrote: > > > > > > > On Fri, Dec 03, 2010 at 09:28:11PM -0500, Jeff Layton wrote: > > > > > So, what does this mean for CIFS clients? I believe that the best > > > > > behavior for the client is to *never* time out an individual request, > > > > > aside from SMB echoes. > > > > > > > > I like this concept. > > > > > > > > > > > That will break apps that can't take ctl-c though ... > > > > > > > How will waiting indefinitely for a response break applications? > > Returning an error just because the server is slow seems far more > > likely to break applications. > > > > Now, in the (IMO unlikely) event that a server is responding to > > echoes but not other calls, you'd have an that application will hang > > until someone kills it. I think that's acceptable however: > > > > It's an unlikely situation, and anyone who has a client faced with it > > has a way to recover from the hang. They can kill the application. The > > server in this case would be clearly broken however. > > > > > I am more worried about firewall rule changes and similar events > than about broken servers - but the idea of waiting forever on stat > to a server that is never going to respond seems odd. > But we won't wait forever...only if the server is still responding to echoes. A server that responds to echoes but not other requests seems very, very odd. -- 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
