Hello,
I seem to be having this exact same issue with several applications that are
loading images into a sequence. If I use share level security, force guest only
or set a user as admin user, I get good speed at around 50MB/s. If set in any
other way, samba doesn't negotiate anything higher than a 4K transfer and
the app slows down to about 5MB/s. All clients are Windows 7. This is also a
GPFS-based system.
I have tried this on 3.5.11 and 3.5.15, both the same behaviour.
Anybody have any idea what this could be or how I could improve on this? We
can't really use the above workarounds because of our security policies.
Many Thanks,
Heather
On Tue, Mar 27, 2012 at 09:13:44AM +0200, Stijn De Smet
wrote:> Hello,
>
> I have a performance problem when I don't connect using root and/or a
user
> in the "admin users".
> Configuration:
> Samba 3.5.11 running on SLES11SP1. The share exported is on a GPFS
> filesystem and the GPFS vfs object is loaded(not loading it doesn't
change
> the described behaviour)
> clients: Windows 7 and Windows 2008R2 all at latest update level.
>
> [testshare]
> comment = testshare
> path = /testfs1/testshare
> read only = no
> force create mode = 0666
> force directory mode = 0777
> force security mode = 0666
> force directory security mode = 0777
> admin users = testuser
>
>
> If I connect using a user other than testuser, I get ~8 MB/s from the
> clients, and if I look at a trace, I can see that all read operations are
> in 4K blocks(Read AndX Request/Response). If I connect using root or
> testuser(which is in the admin users), I get 50MB/s and samba goes up to
> 60KB blocks when reading. Also during the negotiation, I can clearly see
> that "Max Buffer: 0" is set in the "Session Setup AndX
Request,
> NTLMSSP_NEGOTIATE sent by the client, while this is 16644 when connecting
> as root/testuser.
> When switching to "security = share" and using guest access, I
can see the
> same behaviour. Setting force user/group to root gives good performance,
> setting it to something else kills performance.
>
> Is this expected, or am I missing something?
No it's not expected. Something else is going on
here...>