[Samba] Large Directories Timeout smbfs & Windows

[Stan Dolson]

All,

This is my first posting to any of the Samba mailing lists.
I've been a lurker for a year or so as I've been working on
a VFS for the company I'm working for.

We're currently using Samba 3.0.10-4 on RedHat AS 3 Update 4
and we are observing the following problem both with our VFS
and with shares residing in a Linux directory on the Samba
server.

If a directory has lots of files in it (say 20000 or so), we
are seeing both Linux and Windows clients timeout the shares.
The timeouts occur when doing an "ls" on Linux with smbfs or
opening the share's folder on Windows.

Looking at debug logs shows that Samba is in the middle of
doing a TRANSACT2_FINDFIRST (call_trans2findfirst in the code)
where it calls SMB_VFS_OPENDIR, reads all of the entries
through SMB_VFS_READDIR, and then closes the directory with
SMB_VFS_CLOSEDIR before sending any reply at all to the
client.

When either Linux or Windows times out, both will start a
new Samba connection to the share (a new child smbd pid)
and start the whole process over again.  Windows does eventually
give up and give us a dialog box saying that the share is
no longer available.

TRANSACT2_FINDFIRST can take several minutes with 20000 files
and the receive timeouts for both Windows and Linux seem to be
woefully short.  smbfs seems to have a default of 30 seconds.
I'm not sure what the timeout value is for Windows but it
isn't long enough either.

I have successfully retrieved through smbfs a directory
listing by changing the timeout to something large with

   mount -t smbfs -o timeo=300 //computer/share /mnt

The issue is that I cannot seem to find the corresponding
timeout value for Windows.  Does such a thing exist?  How
do I change it so that Windows will also stop timing out?
Am I just out of my mind?

Any help is much appreciated.  I've looked high and low
by searching the web, the bug lists at samba.org, and Microsoft's
support site and come up empty handed.

Thanks!

--
Stan Dolson
Asempra Technology
StanDolson at asempra.com