Kim Malafant wrote:> We are not sure if this is the correct place to send this but we are also
> unsure whether it is a bug or some other strange behaviour. Our apologies
> in advance if this should be sent elsewhere.
It does sound like a networking problem, as you suggested:
let's continue the discussion at samba@lists.samba.org...
A 100 Mbit/S link should peak out at about 6,500 KB/S,
or 6.5 MB/S (newer cards will be faster)
> 1) A machine on one subnet can copy from SAMBA share to SAMBA share with
> reasonable performance and consistently. A copy of about 80Mbytes takes
> approx 2 minutes.
Two minutes? It should take something
like 80/6.5 = 12.3 seconds
That sounds like a problem right there!
> 2) A machine on another subnet does the same copy and it works fine and in
> about the same time. Try it a second time and all of a sudden the time
> blows out to 30 minutes and the copy fails and the connection is lost. A
> look at the log (machine specific) shows (sometimes!) oplock problems which
> from the FAQ indicates a "broken" network card/poor cabling
doesn't it?
> 3) Machines on the same subnet as the SAMBA server generally have no
> problems and are much quicker copying. But not always!
That "local" machines are much faster is also
an indication.
The log entries you're seeing are all from disconnects,
diagnosed at different points in the program:
> request_oplock_break: no response received to oplock break request to pid
> 16749 on port 33722 for dev = 2680062, inode = 486401
> for dev = 2680062, inode = 486401, tv_sec = 3aba92cc, tv_usec = 22e4a
This means that the client is not responding...
> roger (172.16.12.18) closed connection to service testarea
> [2001/03/23 11:15:14, 0, pid=16808, effective(0, 300), real(0, 0)]
> lib/util_sock.c:(540)
> write_socket_data: write failure. Error = Broken pipe
> [2001/03/23 11:15:14, 0, pid=16808, effective(0, 300), real(0, 0)]
> lib/util_sock.c:(566)
And this looks like a write after a client close...>
>
> Routing seems fine as the machines can communicate with each other - ping,
> ftp and telnet between the subnets works fine to the machines and server
> etc etc.
Try the transfer tests with ftp too: it should transfer
at roughly the same speed as Samba (e.g., up to 6.5MB/S)
If not, you have a non-intermittant problem between that
client and the Samba server.
> When something goes wrong the client machine
> freezes, the SAMBA connection "appears" to be lost and the copy
fails.
> However, checking the SAMBA status shows that the session for the machine
> is still connected, as are the shares.
This indicates that Samba hasn't noticed that the client
has disconnected (yet!).
You can add
keepalive = 30
to the global options, to make Samba poll client
connections every 30 seconds to make sure they
haven't gone away. If they have, Samba will clean
up, report an unexpected disconnect in the logs
and update the smbstatus program.
Next you have to find out why the clients are
disconnecting: please see
http://www.geocities.com/orville_torpid/papers/ethernet-note.txt
for some hints on diagnosis.
--dave
--
David Collier-Brown, | Always do right. This will gratify
Performance & Engineering Team | some people and astonish the rest.
Americas Customer Engineering | -- Mark Twain
(905) 415-2849 | davecb@canada.sun.com
