Re: patch for 2.1.65 smbfs

Bill Hawes (
Fri, 21 Nov 1997 09:06:51 -0500

Gordon Chaffee wrote:
> Something is very wrong in 2.1.x for doing the getattr. In 2.0.31,
> I could do an ls -l in an 810 entry directory, and here are the results
> from time ls -l /hosts/feba/d/EMACS-19.34/LISP/:
> 0.11user 0.19system 0:02.56elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+0minor)pagefaults 0swaps
> Compare that to the output in 2.1.x:
> 0.15user 0.33system 2:52.04elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+0minor)pagefaults 0swaps
> That is 2 minutes and 52 seconds versus 2.56 seconds. A factor of 50X
> slower is a pretty dramatic slowdown.

Hi Gordon,
I agree that something is wrong here -- when I do an ls -lR of my entire
NT disk, 11,000+ files takes 59 sec the first time, 25 sec for a repeat
(NT has to fill up its caches.)

> The server is an NT 4.0 machine, so I don't think I can turn anything on.
> I tried using tcpdump-smb to log the network traffic, but it crashes
> almost immediately once it sees a few packets.

Smbfs uses samba to get its network connection, so I though maybe the
Linux-side samba software could show what's going on. When you drop a
connection, a samba process gets a signal and is supposed to open a new
network socket and call a smbfs ioctl. This should happen immediately,
but for some reason doesn't on your system. I'd like to find out whether
the samba process is still responding, and why it fails to get a new