[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bacula-devel] A bug in 2.2.8-jobmedia.patch?


New user signing on! :)

I've got Bacula working here, under NetBSD-currrent on i386 and VAX, and
am truly impressed.  It's flexible and powerful, while surprisingly easy
to set up and maintain.  Congratulations!

Oh, and I'm also using a tape robot; a Compaq (i.e. DEC StorageWorks)
TL891, with a TZ89 (DLT-IV) drive, and 10 slots.  With a locally
modified chio-changer script, it's working great, including the use of
my home made barcode labels! :)

But on to the bug: after testing single backups and restores, including
ones that spanned two tapes, and seeing no problems, I re-initialized
everything, and set it working "for real".  After some time, I noticed
that it was pushing my database server harder than it had before, and I
discovered that it was writing JOBMEDIA records for every block written
to tape.  (I use spooling, so it was doing enough of this to really slow
down the writing to tape tremendously, which is what started me
wondering in the first place.)

Look at 2.2.8-jobmedia.patch; it removes a "dcr->NewVol = false;".  In
fact, it removes several such resets from set_new_volume_parameters(),
replacing them with a call to set_new_file_parameters() -- but the
latter doesn't clear dcr->NewVol.

Here's what I believe happened: my backup jobs were started at the same
time, but not all could run immediately.  The particular job that failed
didn't actually start until the first tape had filled, and a second one
been loaded.  There's code in fixup_device_block_write_error() to set
NewVol to true for all dcrs attached to a volume when it is changed --
so when the job started despooling to the second tape, it had NewVol
set, and thus generated JOBMEDIA rows.  However, the lack of code to
clear that flag caused it to do so for every block, continuously.

After making the following change (which also removes a superfluous line
that should have been taken out as part of 2.2.8-newvol.patch), things
now work as they should:

--- src/stored/block.c~	2008-01-03 15:08:43.000000000 +0100
+++ src/stored/block.c	2008-03-24 15:45:49.000000000 +0100
@@ -374,7 +374,6 @@
       if (dcr->NewVol) {
          /* Note, setting a new volume also handles any pending new file */
          set_new_volume_parameters(dcr);
-         dcr->NewFile = false;        /* this handled for new file too */
       } else {
          set_new_file_parameters(dcr);
       }
--- src/stored/device.c~	2008-03-04 07:56:24.000000000 +0100
+++ src/stored/device.c	2008-03-24 15:43:53.000000000 +0100
@@ -241,6 +241,7 @@
    dcr->VolFirstIndex = 0;
    dcr->VolLastIndex = 0;
    dcr->NewFile = false;
+   dcr->NewVol = false;
    dcr->WroteVol = false;
 }
 
-tih
-- 
Self documenting code isn't. User application constraints don't. --Ed Prochak

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.