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


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.

On Tue, Feb 28, 2012 at 10:43 AM, Jeff Layton  wrote:
> On Mon, 27 Feb 2012 18:01:04 -0600
> Steve French  wrote:
>
>> This is going to be more complicated than it seems.
>>
>> Apparently (according to Chris), Windows will often allow mapmpx simultaneous
>> requests per process for various handle based requests.  In addition according
>> to JRA, Samba server does not care if you go beyond maxmpx (and there is
>> a big performance advantage of that).  On the other hand - if the server
>> sets maxmpx to less than 10, these kind of changes probably make sense
>> (those servers are probably broken otherwise), but for normal servers
>> this will end up restricting more than windows (for more than than the
>> maxmpx per pid).  Generally, for servers like Samba that support
>> simultaneous requests reasonably we have to be careful about killing
>> performance especially now that with Jeff's async reads and writes
>> we will frequently get up to 50 (and should probably make it easier
>> to have more than 50 to servers like Samba).
>>
>> Quoting JRA and Volker - "You should be able to queue
>> thousands of simultaneous requests from one client to Samba"
>> (as long as the client doesn't time out. The server keeps
>> responding to the earlier requests, so with our client timeout
>> code weshould be fine).
>>
>
> The problem here though is that we have to code for the lowest common
> denominator. While many servers handle exceeding the maxmpx gracefully,
> a lot don't. The only safe course here is to respect the MaxMpx by
> default since we can't reliably predict what the effect will be if we
> exceed it.
>
> That said, if you want to add some sort of knob (mount option?) later
> that allows the client to override the server-provided maxmpx, then I'd
> be ok with that.
>
> --
> Jeff Layton 



-- 
Thanks,

Steve

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