smbfs very slow
Urban Widmark
urban at teststation.com
Tue Oct 9 15:03:05 GMT 2001
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
More information about the samba
mailing list