The Samba-Bugzilla – Bug 1205
smbd Stalling on Freebsd.
Last modified: 2004-05-27 03:25:09 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
# Samba config file created using SWAT
# from titan.shires.org (220.127.116.11)
# 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/255.255.255.240 65.xxx.xxx.xxx./255.255.255.192
path = /ccd1/fileserv
read only = No
guest ok = Yes
(IP addresses xx'd for security )
waiting on strace-like output and raw network capture file.
some notes from the samba ml:
Ertan Kucukoglu wrote:
|> We continually work on improving performance
|> as we can. What specifically are you referring
| 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.
guess it wasn't that important. No response from reporter since March.