Bug 3037 - sharing violation during cleanup phase of dbench from cifs to samba
Summary: sharing violation during cleanup phase of dbench from cifs to samba
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.20
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-08-24 20:16 UTC by Steve French
Modified: 2006-04-09 11:14 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Steve French 2005-08-24 20:16:09 UTC
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.
Comment 1 Steve French 2005-08-24 20:19:16 UTC
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
Comment 2 Volker Lendecke 2005-08-25 04:25:38 UTC
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.


Comment 3 Volker Lendecke 2006-04-09 11:14:22 UTC
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.