samba - Oct 2001 - smbfs very slow

Hi.  I downloaded the mailing lists archive (all 90MB of it), and did not
see this problem.  Maybe my searching methods leave something to be
desired; if this is a FAQ, pointers will be appreciated.

I have a Linux 2.4.7, Samba 2.2.1a machine (pc -- both a SMB client and
server), a Win95 machine (superman -- SMB client only), and a Win2000
machine (goliath -- SMB client and server).  They were named by three
people; that's why there's no theme.

When I mount a dir from goliath to pc, using the command

mount -t smbfs -o credentials=/home/eben/goliath.credentials,uid=500
//goliath/catalog ~eben/temp

I can "cd" into ~/temp (as eben), and do an "ls" (or at
least I could
_this_ time, when I tried).  I see what I should.  If I run "strace find
temp2/" from ~, it waits on getdents().  If I wait long enough, it'll
continue, only to get hung up on a getdents() or a some flavor of stat().
If I hit ^C, there's a long wait (minutes to hours), then the process
(usually) exits.

Doind a "cat file > /dev/null" completes in a reasonable time, but
there
was a long delay doing a tab-completion on the filename.

I thought it was "too many files in a directory" causing the problems,
so
I broke up the files.  There are now 27 sub-directories (not counting
hidden ones) totalling ~5700 files.

Every 15 minutes or so, I get these (or something similar to them) in
/var/log/messages:

Oct  3 15:50:06 pc kernel: smb_get_length: recv error = 110
Oct  3 15:50:06 pc kernel: smb_trans2_request: result=-110, setting invalid
Oct  3 15:50:06 pc kernel: smb_retry: successful, new pid=25354, generation=2

The last message is just smbfs reconnecting a mount, and I think the
second one is too.  How about the first one?

I can supply smb.conf, if that's needed.

I upgraded from 2.0.6 (after finding out that 2.0.7 was the first release
to support w2k), so there might be a few bits of 2.0.6 hanging around.  I
know I haven't got rid of the man pages yet..

Thanks for any hints.

-- 
-eben             eben@gate.net           http://home.tampabay.rr.com/hactar/
                    "God does not play dice" -- Einstein
            "Not only does God play dice, he sometimes throws
            them where they can't be seen." -- Stephen Hawking

On Wed, 3 Oct 2001, Hactar wrote:
> I can "cd" into ~/temp (as eben), and do an "ls" (or at
least I could
> _this_ time, when I tried).  I see what I should.  If I run "strace
find
> temp2/" from ~, it waits on getdents().  If I wait long enough,
it'll
> continue, only to get hung up on a getdents() or a some flavor of stat().
> If I hit ^C, there's a long wait (minutes to hours), then the process
> (usually) exits.
Running strace on multithreaded programs on smbfs triggers a known bug
(but find isn't multithreaded). Do you only see the hang problems when
doing strace?

> Doind a "cat file > /dev/null" completes in a reasonable time,
but there
> was a long delay doing a tab-completion on the filename.
> 
> I thought it was "too many files in a directory" causing the
problems, so
> I broke up the files.  There are now 27 sub-directories (not counting
> hidden ones) totalling ~5700 files.
Something that should improve performance for large dirs is to increase
the time the cache is considered valid (default 1 second). Try giving
ttl=10000 (10 seconds) as an option to mount.

> Every 15 minutes or so, I get these (or something similar to them) in
> /var/log/messages:
> 
> Oct  3 15:50:06 pc kernel: smb_get_length: recv error = 110
> Oct  3 15:50:06 pc kernel: smb_trans2_request: result=-110, setting invalid
> Oct  3 15:50:06 pc kernel: smb_retry: successful, new pid=25354,
generation=2
> 
> The last message is just smbfs reconnecting a mount, and I think the
> second one is too.  How about the first one?
ETIMEDOUT, Connection timed out.

The first one triggers the second. And it is a strange error as no one is 
trying to connect. More common are 104 (Connection reset by peer) and from 
2.2 kernels 32 (Broken pipe).

This is just the server disconnecting (because you left the mount idle?), 
it should reconnect and continue to work.

/Urban