Using current dbench (dbench 3.0.3) from
Unpack dbench on the Linux client to e.g. your local homedirectory, build it.
Launch smbd on the same box
mount -t cifs //localhost/sharename /mnt
from the local homedirectory, dbench -D /mnt/targetdir 70
which launches dbench with 70 local processes (cifs client will throttle that
back somewhat) against the remote mounted directory specified. I have also
found failures specifying a much shorter time such as 70 seconds (e.g. dbench -t
70 -D /mnt/targetdir 70)
I see three symptoms against Samba 3.0.20 which I do not see running against
3.0.14a Samba on the same server.
a) oscillating slow response - my traces, polling periodically the pending mid
queue, in the cifs vfs show multiple ReadX and OpenX and Transact2 (do not know
which trans2 subcommand) outstanding for more than 2 seconds, sometimes even a
few over 4 seconds. Have seen a couple timeouts (15 seconds). This is much
longer than expected for only 70 processes (the test machine is 1.2GHz Pentium III)
b) a few read failures (probably caused by the timeout and subsequent session
drop and reconnect). I have seen a couple runs in which there was a session
drop (due to the timeout and the client giving up on a read).
c) cleanup phase errors (looks like sharing violations)
smbfs also returned errors to the same 3.0.20 server during the cleanup phase,
which would need more investigation to track down whether it is an smbfs bug or
server problem (less important issue - but possible confirmation of 3.0.20 problem)
This is clearly not enough data (one test machine, RHEL4 with current kernel
2.6.13) but that it worked to 3.0.14a and not to 3.0.20 (and occurred multiple
times) was worrisome.
I have not completely ruled out that this could somehow be a cifs vfs bug, but
the limited information so far points to the server, and I don't see any
problems on the client side from my traces, and thought it was worth tracking
the issue in any case while more information is gathered
Could you please provide a little more information? For example you could upload
logfiles, your smb.conf and possibly a network sniff somewhere. Without this
information it is a bit difficult to analyze the problem.
No feedback for a couple of months, closing.
If this still happens with 3.0.22 as a server, please re-open and provide more detailed information.