[Samba] Poor Performance

[Jeff Elsloo]

I have a big problem.  I've looked at a bunch of documentation, both for
Windows 2000/NT4, and Samba, and I have yet to find a solution.

Anyway, here's the problem.  We have a Unix File Server with ~2.6tb of
online storage, performance is great over NFS to other Unix machines. 
However, using Samba, I get terrible performance.  Samba ends up eating
almost an entire processor by itself when doing certain operations. 
What's causing this is the number of files we have in a single
directory, anywhere from 50,000 to 200,000 documents in one directory. 
I've truss'ed smbd on the file server, and it appears that after every
write operation the client performs, it asks for a directory listing,
which, as you can imagine, takes some time with the amount of documents
in the single directory.  I've also tried using an NFS client on the
Windows side, and it did the same thing, and was actually *slower*.  In
Unix, I don't have this problem, but moving this particular application
to Unix is impossible.  I also can't break the files down into different
directories.  While reading documentation on both M$'s site, and
samba.org, I found that this may be a read ahead caching issue with
Windows, and that it may be possible to control that via the file
server.  I've tried all different things with oplocks on Samba, and
nothing seems to speed it up, the client is causing smbd to either do a
stat64 or a getdents64, or both, no matter what I do.  The problem isn't
the load on the CPU (though that would be nice to remedy), it's the fact
that it is taking around a minute to copy a file that is under 100k from
Windows to the file server via Samba.  The thing that is slowing
everything down is the directory scanning.

So, the question is..... is there any way to control this via Samba, if
so how, or (and I know this isn't an NT mailing list, but I may as well
ask) is there any way to control this on the Windows side?

Any help would be GREATLY appreciated, replies on or off the list are
fine..

Thanks,

Jeff