On Thursday 09 December 2010 09:53:43 pm Sebastien Caty wrote:
> The more I read on SMB the more my head hurts. Different behavior
> depending on what windows version is running.
Not only that... the VFS interface changes very often (nearly on every minor
release). Too often if you ask me. I would understand if they did minor
changes every now and then, and major ones on every major Samba release (2.x.x
vs. 3.x.x vs. 4.x.x)... but that's the way it is :)!
Also, the VFS API documentation is completely outdated and unclear -- you have
to find things out yourself in major parts. Well, at least there are some VFS
examples (which are up-to-date).
> Anyway, yeah having several connection from the same client is possible and
> not a bug.
> To help with some problem I did have (smbd hanging around to long) I have
> enabled reset on zero VC. It closes all connection from the same IP
> when VC=0, but it seems not all connection from XP are VC=0.
> Unfortunatly, if there is a deadlock it will not shutdown the process
> so it doesn't help for this.
And it's no solution anyway... but there's hope! I may have found the reason
for the deadlocks. I'm currently testing it with a pattern that did hang in
the past (Qt 4.7.1 build tree)... and I'm really pushing it hard :).
If I'm not completely wrong, the deadlock only occurs on reads (opens), and
there's actually some code in my sync-scan routine that could potentially
cause a deadlock by re-requesting synchronous scans (too often). Since the
monitoring thread already takes care for pending scan requests and re-
initiates them on demand, there's no need to do the same in
SVSThreadManager::syncScan() anyway. So I've removed that code and made the
monitoring-thread check more often (100 times a second, it was 10 times
before). This produces just a very small overhead while at the same time being
a bit faster than before (from a user's / application's perspective). And...
at least for me up until now... it seems to also avoid the deadlock.
This is the corresponding change-log entry (SVN rev. 87):
- imp: sync-cans no longer process the request queue themselves, they only put
a scan request on the queue and let the monitoring thread take care of it
(this should also fix the rare deadlocks which were seen by some users)
Fingers crossed :)!
> Never saw that, guess I'm staring at the screen too hard :P
It's not really important for now because I only use it to distinguish between
log-output from different sessions (just 'grep' the session ID in
/var/log/messages), but it will be required to be unique for other features
later, so I need to make sure it really works as expected. Would be nice if
you could keep an eye on it as well!
> BTW, this is on SLES9. QT 4.5.3
My setup: openSUSE 11.3 (x86_64), Qt 4.6.3, ClamAV 0.96.5, Samba 3.4
BTW, please post (more) complete logs next time if possible... something like
this would be nice (output attached to the mail):
# grep <session-ID> /var/log/messages | bzip2 > session.log.bz2
Have fun, René
Anything is good and useful if it's made of chocolate.