[linux-cifs] Re: [PATCH 06/11] CIFS: Respect MaxMpxCount field


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  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 28 Feb 2012 11:42:49 -0600
> Steve French  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 
> -----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

This message from: http://www.mailbrowse.com/linux-cifs/5551.html
Previous message: Re: [linux-cifs-client] [PATCH] cifs: hard mount option behaviour implementation
Next message:Re: [PATCH 06/11] CIFS: Respect MaxMpxCount field