On Fri, 17 Feb 2012 23:58:41 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > I am not convinced that we need to keep enough echo retries ... probably ok > to be able to send one echo if we have 49 other requests pending, but don't > think it makes sense to reserve more - if the first echo times out, we can > probably simply exceed negotiated mpxcount - the session would be going > down anyway. Why would we have to save more than one for oplock - if we > receive multiple breaks, we simply process them serially. > I agree to a point. I think the code that does echoes and handles reconnects based on it could use some work. There's virtually no reason to resend an echo request if the server didn't respond to the last one. We are using TCP after all, so presumably the echo request won't get dropped by the networking layer. That probably means we can just hardcode echo_retries to 1 and get rid of that module parm. Keeping one slot open to handle echoes is probably reasonable in most cases. In the event that maxmpx is 1 though we can't reasonably send an echo when the server goes unresponsive since we won't have a slot. In that case, I suggest we just don't send any echoes, and simply reconnect if there is an outstanding call to which the server hasn't responded in a certain amount of time. Exceeding the maxmpx though is not a good idea. Servers send that value for a reason and we shouldn't ignore it. Some may handle it gracefully, but there are a lot of crappy CIFS servers in the field and many of them don't handle exceeding the maxmpx well. Best not to do that even if it seems expedient. Oplock breaks are a bigger problem. When we get an oplock break, we have to do more than just send the response to that. We often have to initiate writeback as well. We need to keep at least one slot open for that so we don't deadlock, but how best to ensure that the writeback can proceed? If only the oplock break response is allowed to use the reserved slot, then that potentially leaves writeback hung waiting for a slot. What may make sense is to allow writes to dip into the emergency credit "pool" too if we're writing out of the cache and the inode doesn't have an oplock that allows caching of writes. In practice, it might even make sense to disable writing to the cache when the number of slots is low but still more than 2 (maybe less than 5 or so?). Writable oplocks aren't terribly helpful when the throughput to the server is low since it can take a long time to do writeback. Probably that threshold could be made tunable somehow. -- 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
