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

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


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
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.