3.0.4-3.0.6

[William Jojo]

Turns out it wasn't that. Although I took a hit with "wide links = no" (as
you pointed out), I was still taking a hit with it set to yes. The
symptoms were sluggish responses to directory contents and resolving
values in security tabs from properties.

I went back to 3.0.6 and large readwrite = yes (the default) was my
problem all along. I was attributing slowness due to the number of system
calls, but it was really this parameter.

AIX was doing kpread/send on 32K boundaries which for some reason was
really irritating my WinXP(sp1) client.

I turned off large readwrite and it went back to the "max xmit" default
value of 16644. This really made the WinXP(sp1) client very happy - of
course I'd like to understand why that is the case as I don't ever recall
having to change large r/w with 2.2.8a.

I then set "wide links = false" to see what you were referring to with a
more snappy environment and I could definitely see the difference so I'll
just leave that one alone ;-)


Thanks for you help (as always!) Jeremy!


Bill


On Wed, 1 Sep 2004, Jeremy Allison wrote:

> On Wed, Sep 01, 2004 at 02:17:56PM -0400, William Jojo wrote:
> >
> >
> > Sorry, I added those entries after discovering the high volume of syscalls
> > and they seemed unchanged.
> >
> > I'm still working in the log levels on separate servers and I'll truss
> > them as well to see the differences between behaviours and then dig into
> > the code to understand better.
>
> Well removing the entries is what I had in mind. Can you add a debug
> to see if realpath() is being called ? You can find the call in smbd/vfs.c
> reduce_name(). This shouldn't be being called unless wide links is set to
> false.
>
> Jeremy.
>