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

On Tue, Feb 28, 2012 at 2:53 PM, Pavel Shilovsky  wrote:
> 2012/2/29 Steve French :
>> 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

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).



This message from: http://www.mailbrowse.com/linux-cifs/5553.html
Previous message: Re: [linux-cifs-client] [PATCH] cifs: hard mount option behaviour implementation
Next message:[patch] cifs: writing past end of struct in cifs_convert_address()