[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] A bug in 2.2.8-jobmedia.patch?
Kern Sibbald <kern@xxxxxxxxxxx> writes:
> I suspect that has something to do with the fact that you are using
> spooling, and they record the start block early in the game at the
> beginning of the spooling and the code is not intelligent enough to
> wait until the very first block is actually written to *tape*.
That is correct. In stored/append.c, in do_append_data(), there are two
calls to write_session_label(), performed at the start and end of
spooling to a disk file. These calls, which generate session labels in
the disk file, marking the start and end of the session, both cause
information about the current tape position to be recorded in the job's
This has two specific consequences:
- If several jobs start spooling at the same time, they will all get the
current tape position noted as the StartFile/StartBlock for the job.
If they end up despooling to the file that was current when they
started spooling, this is what will end up in the JOBMEDIA table. If
there is a file change before they despool, the setting of NewFile in
the dcr structure will fix this up later, but the "start of session"
label is already in the spool file, of course, so it holds the wrong
- If the job is longer than the maximum spool size, it will get its
first spool session despooled, and then start spooling again after the
first despooling is over. The last blocks despooled to tape from the
first session will not have been recorded, but they will be flushed
later, when the next session despools. However, if another job has
been despooling while this one is spooling its second round, the
session label written to the spool file at its close will cause the
EndFile/Endblock to be set to wherever the tape is at that time. When
the dangling record is flushed to JOBMEDIA, it gets this wrong
information. Both session labels in the spool file will be wrong,
too, of course, because they reflect the state of the tape during
spooling, not during despooling.
I would have to study the code much more closely to work out what's the
proper fix -- but it seems clear that it should involve creating the
session labels only when something is actually written to the archive
device, not during spooling. I'm tempted to try making do_append_data()
not create session labels if we're spooling, and add the making of them
to despool_data() in stored/spool.c. Sound reasonable?
Self documenting code isn't. User application constraints don't. --Ed Prochak
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.