Bug 1205 - smbd Stalling on Freebsd.
smbd Stalling on Freebsd.
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All FreeBSD
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Depends on:
  Show dependency treegraph
Reported: 2004-03-22 10:26 UTC by Davon Shire
Modified: 2004-05-27 03:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Davon Shire 2004-03-22 10:26:50 UTC
Please see link for full rant/problem explaination.

I was contacted and it was suggested that no answer could be found for this
without a tcpdump and a strace of the offending program. But there are some
difficulties in complying.

1 is this server is a FreeBSD server 5.1pl13 and strace does not run on this
branch of FreeBSD because Strace is predominantly a Linux debugging tool. From
reading the README.freebsd in Strace it appears to work marginally in 4.x branch.

The other problem is that the network is hubbed on switches. So the server would
have to be doing the tcpdump while it was trying to serve files. 

As you can see I'm providing pretty much the default config file since this is
what SWAT puts together initially.

(Note: Any complaints about special flags not being used or network settings not
found in this conf file will be met with some predjudice since we're now at V3.0
of Samba  an if it can't configure itself or aid in proper configuring to a
nearly layman's level. Then something is seriously wrong. )

If there is a special debug flag that needs to be set so you can get the info
you need please let me know. The documentatin for debug and debug logging is
pretty sparse.

# Samba config file created using SWAT
# from titan.shires.org (
# Date: 2003/08/06 06:07:51

# Global parameters
	workgroup = GENERAL
	netbios name = BFS
	interfaces = fxp0
	security = SHARE
	encrypt passwords = Yes
	guest account = mare
	hosts allow = 207.xx.xx.xx/ 65.xxx.xxx.xxx./

	path = /ccd1/fileserv
	read only = No
	guest ok = Yes
(IP addresses xx'd for security )
Comment 1 Gerald (Jerry) Carter 2004-03-22 11:37:10 UTC
waiting on strace-like output and raw network capture file.
Comment 2 Gerald (Jerry) Carter 2004-03-25 13:46:47 UTC
some notes from the samba ml:

Ertan Kucukoglu wrote:

|> We continually work on improving performance
|> as we can.  What specifically are you referring
|> to?
| I referred to Davon Shire's e-mail dated 09 March
| 2004 18:59.
| In the mean time, I remember some programs indicate
| performance gain by  percentage. I do not remember any
| name in my mind. But, IMHO similiar approach maybe
| good for samba.

We actually gained significant performance improvements
with the "TDB scalability issue surrounding the
TDB_CLEAR_IF_FIRST flag".  This will be mainly seen by
larger installations (maybe >100 concurrent connections).

I missed Davon's mail the first time (the danger of the
signal-to-noise ration on this list sometimes).

Here's the gist:

| SMB transfer from Client1 to Client2 6.0 MB/s both ways.
| FTP transfers: average 8.7 MB/s from Server to Client1.
|   5.7 MB/s from client1 to Server.
|  FTP transfers: average 9.0 MB/s from Server to Client2.
|   6.0 MB/s from Client2 to Server.

| ( Yes there is some noted asymetry here but the data flow
| over the network is smooth, there are no pauses or breaks
| in the data transmission. )
| Samba Transfers: Average 6.0 MB/s from Client1/2 to
| Server. 1.75 MB/s from server to Client1/2. (does not
| matter which machine, they both produce almost identical
| network behavior.)
| ( The reason the average from server to clients is so
| low is due to unexplainable lulls in transmission from
| the server to the client. Peaks in the transfer near
| 6.0 MB at times. )
| I have as previously stated tweaked, recompiled, adjusted.
| read dozens of performance tips for getting the most out
| of Samba and it's just not happening. I've adjusted read
| size, Sendbuf and Recvbuf values, MTU, MSS, lowday, no
| delay blah blah blah. I've watched for collisions.
| (None) I've watched for NACKS ACKS and the last episode
| of The Tick. But I can't get much better than I already
| have out of these machines.
| If I'm missing something obvious please tell me. But
| if it's obvious then why isn't it working straight out
| of the Install?

If I were going to start trouble shooting this I would
need to see a network trace to see what the packet previous
to the stall was.  We would also need to know what the smbd
process was doing during the stall using strace (i.e. was
it waiting for a repsonse such as an oplock break or was
it looking for some data in a tdb, etc...).

And as a final note, bugs will get lost on this list.  The
\preferred method of tracking defects is to log a reoprt at

So Devon, if you would be will to open a bug report and
provide me with the requested information, I'll try to burn
some cycles on it.

Comment 3 Gerald (Jerry) Carter 2004-05-27 03:25:09 UTC
guess it wasn't that important.  No response from reporter since March.