failures in smbtorture, dbench and friends
J. Robert von Behren
jrvb at cs.berkeley.edu
Sat Aug 19 07:45:38 GMT 2000
To throw a bit more fuel (but unfortunately no further clues) on the
fire, I've seen the exact same behavior on a couple of Linux test
servers I've been playing with - lots of "nb_close: handle XXX was not
open" and "write failed on handle XXXX" errors, and correspondingly
bogus results. I've seen this on several different Linux kernel
versions (in the 2.3.99 and 2.4.0-test series), and with both the stock
Samba 2.0.7 and a couple of snapshots from the main branch of the CVS
The problem appears somewhat random, although it seems to happen more
often with larger numbers of clients in smbtorture. I'd be happy to do
some additional exploration if anyone has ideas of things to try. (I'll
have only intermittent email contact until 8/27, however, so I may not
be able to do much until after then.)
-Rob von Behren
acherry at pobox.com wrote:
> David Collier-Brown writes:
> > acherry at pobox.com wrote:
> > It turns out that the dbench suite doesn't report
> > a common failure mode: running out of space. Instead
> > it tries to continue, and the numbers are skewed.
> > I've changed dbench to have it suicide on out-of-space
> > instead of telling fibs, and will send back the diffs
> > after I give the whole suite a more thorough tryout.
> > Anyone who wants them now, send me email.
> Thanks for your response...
> It looks like I'm not dealing with the same issue you had; there's
> plenty of disk space for the "netbench" share, and I don't even come
> close to running out. I've tried this on both an Ultra 60 and an
> Enterprise 4500, with the same results.
> The symptoms I get are a few sporadic "nb_close: handle XXX was not
> open" and "write failed on handle XXXX" early on in the test. At some
> point later in the test (several lines of dots), I get a whole flood of
> the above messages; eventually it starts segfaulting when the +*+*
> starts appearing (popping up a few xterms with gdb running). Nothing
> ever appears in the log.smb on the Samba system to indicate anything
> wrong on the server side. (BTW, I get this cosistently whether I run
> on the same machine Samba is running on or on a different system).
> I'm not running Solaris 8, however; I'm using Solaris 2.6. This sort
> of thing did happen to me the last time I tried using smbtorture
> (maybe a year ago).
> Unfortunately, I don't have any non-Solaris UNIX boxes to try running
> smbtorture on, so it's hard to determine which end (client or server)
> the problem is on. The only other possibility would be to comandeer a
> PC and throw a Linux install on it to try it as a client...but my end
> goal is to get smbtorture working on one of our cluster machines and
> point it to the other one (taking advantage of the gigabit Ethernet
> My builds of Samba 2.0.7 and smbtorture were both done with the Workshop 5.0
> C compilers, if that matters any.
> I've also tried the CVS version of smbtorture, but run into the same issues.
> Any thoughts as to what might be going on? Has anyone on the list
> ever tried running smbtorture under Solaris 2.6, or seen this behavior
> in situations other than a full disk?
More information about the samba-technical