smbfs very slow

[Urban Widmark]

On Thu, 4 Oct 2001, Hactar wrote:

> On Thu, 4 Oct 2001, Urban Widmark wrote:
> 
> > Ok, I have other reports of things failing with longer dir listings /
> > larger dircache operations. I'll probably do some ls/find tests this
> > weekend.
> 
> Thanks.

I am unable to produce any kind of failures (a few dirs with about 12000
files each, ls, ls -l, find, ...). Tested vs samba 2.2.2-pre, win2k and
NT4sp6. Pretending I only have 64M in the box does not trigger anything.
Any ideas why your files are so special?

Consistently about 50 seconds to run one of the find operations I used
(which is "reasonable").


The error messages you describe suggests that the connection is being
dropped. If you take a network dump (tcpdump or ethereal) can you see any
disconnects in the middle? Or other interesting effects?


The network traffic caused by smbfs serving a 'ls -l' is basically this:

Client calls getdents() which causes smbfs to do a "readdir". Each of
these smbs return a piece of the dir listing (complete inode info is read
from these).
	FIND_FIRST
	FIND_NEXT
	FIND_NEXT
	FIND_NEXT
	...

After getdents ls -l will stat() each entry to get the full inode info.
(color ls and other stupid things also need to stat).

That info is cached from the readdir call, but the time-to-live and the
time it took to fetch the list determines if these stat's will trust the
cached info or refresh each inode.

Refreshing a single inode is done by sending a "TRANS2_QPATHINFO", so a
series of messages like these are normal and should go away if the ttl
parameter is increased:
	TRANS2_QPATHINFO
	TRANS2_QPATHINFO
	...

If the server disconnects during these FIND_NEXT's I suppose that could
confuse smbfs and possibly hang it like you describe. But that's just an
idea, I can't get that to happen.


If you can take a tcpdump (tcpdump -w /tmp/foo.trc -s 1600 port 139) and
put it somewhere I can download it from, I can have a look. It may be
pretty big ... 


Other things you could do is try to find out what it manages to do before
it fails and/or where it fails (other than in get_length which is called
from everywhere), using printk-debugging. The startingpoint for 'ls' is, 
in the kernel sources:
	fs/smbfs/dir.c:smb_readdir
and that one uses
	fs/smbfs/proc.c:smb_proc_readdir_long and smb_decode_long_dirent

Either enable the debug flags in fs/smbfs/Makefile or sprinkle liberally
with your own printk's (or copy and rename the VERBOSE debug macro in
smb_debug.h)

/Urban