On Tue, Feb 28, 2012 at 2:53 PM, Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > 2012/2/29 Steve French <smfrench@xxxxxxxxx>: >> Attempt to summarize after discussions with jra and Chris: >> >> - don't make default case to Samba worse performance than it already is >> - don't "fix" by adding restrictions on echo retries and blocking >> locks when it is not broken (windows allows these, and counts blocking >> locks against the pid not against the session). For servers which >> allow few mpx, perhaps those for 10 or fewer - if you think they are >> buggy, I don't mind treating echo and blocking locks differently than >> we do now - but echo and blocking locks don't need to be restricted >> the way Pavel suggested to windows and samba and any normal server >> (and there is some risk in restricting them that way). We could >> probably limit the number of blocking locks (out of resource error, >> returning ENOLOCK) when there are 50 (e.g.) on a process (or 10 if the >> server supports maxmpx of 10, and zero if maxmpx is less than 3 or >> less than 10). >> - for other smb requests (the ones we enforce today) enforce the limit >> the server returns (rather than 50 always) >> > > But for SMB2 we need to count both echos and blocking locks. It even > more compicated because the number of credits is dynamic: we need to > increment/decrement the maximum number of parallel blocking locks to > make sure we don't exceed available credits. Yes - for smb2 the number of available requests (credits) can change on ANY smb2 response. It is not related to how cifs requests are processed. Also note that for cifs for Windows, apparently the smb echo is handled at a lower level (before checking mpx) - (and also Samba server does not enforce either). -- Thanks, Steve -- 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
