Kern Sibbald wrote:
> PS: If you want this problem fixed in the near future, please find someone
> that can submit a patch, but I won't accept any patch on this unless the
> person discusses the implementation detail beforehand as it is a non-trivial
> problem to fix.
Graham,
In the meantime, it seems to me there are two fairly simple ways of
working around this problem, if you're unable to avoid the situation
where one job begins very shortly after another with only one volume
available.
1. If you set the allowed jobs per volume higher than 1, the two jobs
will be able to run concurrently with records interleaved on the same
volume. Your second volume will be mounted after the first one fills.
2. If it is absolutely non-negotiable that there be only one job per
volume, you can set one of the two jobs to a lesser priority. It will
then wait for the first job to complete before it runs, which will allow
the volume filled by the first job to be unmounted and your second
volume to be mounted for the second job.
If for some reason neither of these is acceptable - which is to say, if
it is an absolute hard requirement that both jobs run concurrently AND
that each have only one job per volume - then it seems to me you have
little choice but to run a second storage daemon to enable you to have
two volumes mounted simultaneously. No solution to this particular
volume-allocation corner case is going to change that. By setting up
the requirements and configuration the way you have, you've painted
yourself into a corner in which two jobs running concurrently must both
have exclusive access to a volume, and the only way to satisfy that
requirement is to have two volumes mounted, which can in turn only be
satisfied by using two SDs. (If I were doing it, I'd dedicate a
separate pool to each SD, and an SD to each job.)
As a side note, it seems to me that one possible long-term fix for the
particular corner-case of volumes getting overwritten in situations like
this one would be to allow a volume to be locked for exclusive use when
a job starts, even before a JobMedia record has been created. But note
that this would *also* prevent the second job from running until the
first has completed, just like the priority workaround noted above, so
if you absolutely must have both jobs running concurrently, this still
would not solve your particular problem.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
