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) On Tue, Feb 28, 2012 at 1:47 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 28 Feb 2012 11:42:49 -0600 > Steve French <smfrench@xxxxxxxxx> wrote: > >> I think the best way to handle this is to do the special casing >> (limiting retries, turning off byte range blocking locks, turning off >> oplock) for the servers which do limit maxmpx to small values. For >> maxmpx=50 or higher (or if you wish to narrow this, distinguish >> servers like Samba more narrowly by check for the unix extensions that >> is fine) which shouldn't be stricter than windows (whose client will >> exceed 50 simultaneous requests for various cases Chris described). >> There is a significant chance of deadlock if we don't allow writes >> through due to counting blocking byte range locks against maxmpx too >> strictly. We do have to fix the case of maxmpx = 1 or 2 (disable >> oplock and possibly echo) and enforce maxmpx for those which set it >> lower than 50 - but the byte range lock issue has never come up, and >> fixing it the way pavel describes would be stricter than windows and >> risk deadlock by chewing up slots. >> >> Another issue is that we are significantly underutilizes Samba by >> setting maxmpx so low, but if we expect to move to SMB2 soon, it may >> not matter. >> > > I'm having a hard time understanding what you're proposing above. It > sounds like you're saying that when the server sends maxmpx >= 50 that > you think we should effectively treat that as unlimited? > > Can you lay out the "rules" (and the exceptions thereof) that you're > proposing here? > > - -- > Jeff Layton <jlayton@xxxxxxxxx> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (GNU/Linux) > > iQIcBAEBAgAGBQJPTS9YAAoJEAAOaEEZVoIVduYQANVGfFMVX0Z2TKKcPXN5NsUX > aGssTTToK2JK6kSbKFmSxQHCmD4nSPHc3W5qpsk4VQ0F5KC6tuNMowcWHJaZ/f2f > Qo2TiH7jgRneWOv2y7dxZ66Gs+1mPPIVREhHq0EJzVH/WPcUq+VRkwl3O8k+WQOh > QVZYoj5Aap/sKzwjdX5LcS4jUEuqXVZG/np216grKr1zKpgo4fAXk22sFrpivKyP > XUyyP6SU5EAg2EbA7lbEGGmmfQz7HRiWZ+Vnwd9gdbA1up6vtaSF4ms5aiE6y+XN > c+kaGvgP6EWnNblavEEOJd9+dksHQ5fXRo6t3rGvFmdkAGZlk6kCse6N6zaKnpCi > XEeoIhq/FDAlUNmU7/B4IoXkHqrf7LgXQvycuP3iUFK5N61FfO+NQvtOuHhhbhH8 > c4JoiVheQKJh3DJww6DkrLmmjKhwf1byrsYLyCs0Xm/YyK//tlKeN3zF0hS3j8f8 > f17P1QyeE1E+FWd+QEThTKuR5vMNcCA4yBFctC7gidi98vPY2L6+xNTqUWZkUTdr > pBSiKahXms8oNyvf1ijqoy99wRLIOL0fXLUIBF/NXDw0Gy4YmJvR5PKewoXQYu+R > JEITC1MPiizA7YKgx37OmkERGpVl97r9QS2FvpSUhBfsgoXOKWR4cs+7KPGZQBBF > Ao/y7L/DAVGFoYbMuTZF > =jJfp > -----END PGP SIGNATURE----- -- 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
