On Monday 28 November 2005 16:22, Joshua Myles wrote:
> On 11/15/2005 08:07 AM, Kern Sibbald wrote:
> > On Tuesday 15 November 2005 13:59, Joshua Myles wrote:
> >>On 11/14/2005 04:45 PM, Kern Sibbald wrote:
> >>>I just took a look at my multiple drive regression test. In fact, I ran
> >>>it to make sure it works. Yes, it works, and it writes on both drives.
> >>>However I'm really embarassed to say that I was completely wrong -- it
> >>>does not write to two drives simultaneously. There seems to be
> >>> something wrong with the drive selection algorithm as I planned it that
> >>> does not select the second drive when the second job is started.
> >>
> >>Ah, okay. That explains what I'm seeing; thanks for looking into it.
> >>
> >>Here's hoping it's a simple bug to fix...
> >
> > Quite possibly. It will take me a few weeks to get back to it. In any
> > case, even if it is not critical, I consider it one of the bugs on the
> > top of my list.
>
> Does this need to have a bug report created?
It would be a good idea to create a bug report, but doing so will not get it
fixed. Please see below for why and my suggestions ...
> I didn't see one for it in the bug tracker.
Problems of this nature, and there are several, are so complicated that I have
no way to reproduce them and hence no way to fix them (they are just too
complex and possibly timing dependent). So, their solution is going to
require slightly different techniques. For both you an Arno, who has
similarly complicated problems, I think the best approach is the following:
I have a set of regression scripts that will run on virtually anyone's
machine. You will need to checkout these regression scripts from the CVS
(under module regress) get them running at your site, taking care not to run
them on a machine with a production database unless you are sure you use a
different database (or SQLite) in the regression script (it can use any of
the 4 supported databases). This is because each script is independent, and
hence totally reinitializes the database it is using. I typically use
SQLite, because the script then is totally self-contained.
Then you will need to create a script (by adapting one) to reproduce your
problem. I'll be very happy to help with this phase (you don't need to be a
super script jocky) by creating a first cut of a script. Once we have a
script that fails on your machine, I can then easily run it here and
reproduce the problem. If I can reproduce the problem, I will be able to fix
it.
For Arno, I have created a new script that is similar to the setup that is
failing for him as he describes it, and now it is time for him to run that
script and then modify it to create the failure. Arno's script is called
tests/two-pool-tape. For the moment, it is not included in the standard
scripts run by ./do_all because it is quite long running. Once we have
created a script that fails, I will add it to the standard regression scripts
I run so that once the bug is fixed, it will never come back.
What do you think?
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
