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

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

On Sunday 30 March 2008 19:16:07 Tom Ivar Helbekkmo wrote:
> Kern Sibbald <kern@xxxxxxxxxxx> writes:
> > I have made a simple patch, which seems to correct the problem.
> > [...]
> > It is committed to the trunk, but I am doing a bit more testing on the
> > 2.2.9 branch before applying it.  I would appreciate to know if it fixes
> > your problem.
> That should fix the most common case of the multiple small jobs starting
> spooling at the same time.  I've applied it, and will check that this
> does, in fact, happen, and report back.
> It won't do anything for the case of a large job spooling in two or more
> iterations, of course.  

Yes, I need to think about that issue, but off hand, I don't think there is 
any problem.  No job media records are generated during the spooling.  They 
are only generated before the job starts writing, during writing the tape, 
and at the end of the job.  We were getting in trouble only when the job 
starts writing.  The session_label (end) subroutine temporarily put incorrect 
values in for the end during spooling, but that is corrected during actual 
writing (as far as I can tell).

Still I have some doubts about what gets put in the jobmedia for the start of 
a second despooling call.

> It also won't make the session labels in the backup files correct.  

The session labels don't contain any position dependent data, so that is not 

> How big a problem is that?  What are these labels 
> actually used for?  

They are critical when bscanning a tape to know why a new job "starts" and a 
current job "ends".

> Only to rebuild a lost catalog from the raw tapes? 


> I've got half a mind to make the change that I outlined locally, and do
> some testing.  I reckon I can set up a local file based archive to be
> able to test non-spooled backups and quickly check their in-file labels.

If you can convince/show me that something is going wrong with multiple 
spoolings, then your suggestion becomes much more important.

However, I have always been unhappy that capturing the Volume position was 
done in the session label subroutine (it is sort of hidden there), so I would 
be more inclined to move the end code out into a new subroutine, like I have 
already done for the set_start_vol_position(), then remove it from the 
session_label() subroutine, and call the two subroutines at the appropriate 
times -- that makes what is actually going on much clearer.

Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.