[Samba] Slow on one client Win7 program

[Jeremy Allison]

On Tue, Sep 25, 2012 at 08:22:31AM +0200, Huibert van Andel 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.