Increasing response times for byte range unlock requests.

[Hemanth Thummala]

Hi Jeremy,

Clients are running SMB2. We haven't tested with SMB1 clients.

I think I  have identified the problem. When the blocking lock requests are
reprocessed successfully, we are not removing them from pending queue in
function reprocess_blocked_smb2_lock().

With the following changes, we did not observe any further degradation in
unlock responses.

bash-4.0$ diff -up smbd/smb2_lock.c.orig smbd/smb2_lock.c
--- smbd/smb2_lock.c.orig       2014-06-24 21:43:25.300420642 -0700
+++ smbd/smb2_lock.c    2014-06-24 21:43:33.290457365 -0700
@@ -745,6 +745,10 @@ static void reprocess_blocked_smb2_lock(
                if (NT_STATUS_IS_ERR(status)) {
                        break;
                }
+               else {
+                       /* Removed it from pending queue.*/
+                       remove_pending_lock(state, blr);
+               }
        }

        if(blr->lock_num == state->lock_count) {

Please let me know if this change looks fine.

I will also raise a bug and update all the details.

Thanks,
Hemanth.



On Wed, Jun 25, 2014 at 10:00 AM, Jeremy Allison <jra at samba.org> wrote:

> On Mon, Jun 23, 2014 at 07:09:13PM +0530, Hemanth Thummala wrote:
> > Hi All,
> >
> > We are running samba 3.6.12 stack. And seeing a strange issue where in
> the
> > response time for byte-range unlock requests are increasing when running
> a
> > specific test. Each run response time is growing exponentially.
> >
> > Script used for the test is:
> >
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365204%28v=vs.85%29.aspx
> .
> > Its the second test.
> >
> > This is basically a multi-thread based byte range lock test where in all
> > threads will request for a specific range either exclusively or shared
> mode
> > to access a particular record. All these requests are blocking type(no
> fail
> > immediately flag in request)
>
> One quick question - is the client running
> over SMB2 or SMB1 ?
>
> I just went through the SMB1 code very
> carefully, and that code removes all
> blocking lock records on completion.
>
> I am willing to bet this is less well
> tested with SMB2 (this code isn't used
> much in real-world applications) and
> I think it's possible the blocking lock
> record gets left on the queue in the
> same completion condition for SMB2.
>
> I'll look some more and confirm tomorrow,
> but knowing if your specific test case
> is SMB1 or SMB2 would help a lot.
>
> Cheers,
>
>         Jeremy
>