Hi,
Thanks for this *very good* bug report. Yes jobmedia patch have
the problem that you report.
We just have fixed it before your email :)
I will upload a patch for the patch on sourceforge.
Thanks a lot.
Bye
On Tuesday 25 March 2008 09:24:20 Tom Ivar Helbekkmo wrote:
> 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
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
