[Samba] Slow on one client Win7 program

[Huibert van Andel]

Op 25-9-2012 19:21, Jeremy schreef:
> On Tue, Sep 25, 2012 at 08:22:31AM +0200, Huibert wrote:
>>> Got one program that is running very, very slow on version 3.6.8.
>>> Using SMB2, logging level 3 I saw a lot of these:
>>>
>>> [2012/09/24 23:44:43.824970,  3] smbd/smb2_read.c:356(smb2_read_complete)
>>>   smbd_smb2_read: fnum=[8523/filename] length=2 offset=1656 read=2
>>> [2012/09/24 23:44:43.825499,  3] lib/util.c:1498(fcntl_getlock)
>>>   fcntl_getlock: fd 34 is returned info 2 pid 0
>>>
>>> Seems the files are read in chunks of 2 bytes a call.
>>> Most of the files the program is reading are a few Mb,
>>> so why is it only reading 2 bytes at a time?
>>>
>>> In ver 3.6.7 I made a few tests also, and it does matter what you choose
>>> for locking, e.g.:
>>>
>>>         kernel oplocks = no
>>>         oplocks = no
>>>         level2 oplocks = yes
>>>
>>> Some tests worked better (e.g. no locks at all), some not, though
>>> with 3.6.8 none provides speed.
>>> Anyway 3.6.7 had other bugs and was unusable.
>>> Other programs seem not to be affected (poss. they don't use smb2?).
>>>
>> Another few tests does make a difference:
>>          kernel oplocks = no
>>          oplocks = yes
>>          level2 oplocks = yes
>>
>> Output e.g.:
>> [2012/09/25 08:17:39.042639,  3] smbd/smb2_read.c:356(smb2_read_complete)
>>    smbd_smb2_read: fnum=[4824/filename] length=65536 offset=4030464
>> read=65536
>> [2012/09/25 08:17:39.046235,  3] smbd/smb2_read.c:356(smb2_read_complete)
>>    smbd_smb2_read: fnum=[4824/filename] length=65536 offset=4096000
>> read=65536
>> [2012/09/25 08:17:39.050502,  3] smbd/smb2_read.c:356(smb2_read_complete)
>>    smbd_smb2_read: fnum=[4824/filename] length=32768 offset=4161536
>> read=32768
>>
>>
>> Seems oplocks = yes is fairly stable to give large reads and speed.
>> But why is this?
> That's just the way the protocols work. Many apps use no local
> buffering, and do ridiculously small IO having only been tested
> on a local disk (MS can be blamed here for not encouraging developers to
> use portable stdio, but to make direct syscalls with ReadFile()
> and WriteFile() - makes apps harder to port to UNIX).
>
> In order to make apps run at a reasonable rate against a remote
> share the Windows client redirector gets oplocks and then batches
> the small syscall IO into larger 64k network IO, which is why when
> you have oplocks on you'll get good performance, and terrible
> performance without.
>
> Jeremy.
Am I correct that with *not* using SMB2 the windows 7 client director is
not doing this optimization?

I never got this good using a 3.0 version samba.
Any selection of locks and other settings.

-Huibert.