In the message dated: Mon, 05 Nov 2012 13:28:52 PST,
The pithy ruminations from Stephen Thompson on
<Re: [Bacula-users] wanted on DEVICE-0, is in use by device DEVICE-1> were:
=> On 11/05/2012 01:17 PM, Josh Fisher wrote:
=> >
=> > On 11/5/2012 11:03 AM, Stephen Thompson wrote:
=> >>
=> >> On 11/5/12 7:59 AM, John Drescher wrote:
=> >>>> I've had the following problem for ages (meaning multiple major
=> >>>> revisions of bacula) and I've seen this come up from time to time on the
=> >>>> mailing list, but I've never actually seen a resolution (please point me
=> >>>> to one if it's been found).
If I understand your question correctly, I've seen the same behavior in our
installation, and also haven't found an answer.
[SNIP!]
=> >>>>
=> >>> I do not have a good solution but I know by default bacula does not
=> >>> want to load the same pool into more than 1 storage device at the same
=> >>> time.
=> >>>
=> >>> John
=> >>>
=> >> I think it's something in the automated logic. Because if I launch jobs
=> >> by hand (same pool across 2 tapes devices in same autochanger)
=> >> everything works fine. I think it has more to do with the Scheduler
=> >> assigning the same same Volume to all jobs and then not wanting to
=> >> change that choice if that Volume is in use.
=> >
=> > When both jobs start at the same time and same priority, they see the
=> > same exact "next available volume" for the pool, and so both select the
=> > same volume. When they select different drives, it is a problem, since
=> > the volume can only be in one drive.
That's the best explanation I've seen so far.
=> >
=> > When you start the jobs manually, I assume you are starting them at
=> > different times. This works, because the first job is up and running
=> > with the volume loaded before the second job begins its selection
=> > process. One way to handle this issue is to have a different Schedule
=> > for each job and start the jobs at different times with one second
=> > spacing. Jobs will still run concurrently, they just won't start up
=> > concurrently.
I suggest that the proper way to handle this is within Bacula's scheduler,
not by having people manually add "random" numbers to each scheduler
entry to avoid contention...it doesn't scale on large installations,
it makes scheduler maintenance much more difficult, and that's the sort
of things that computers do well, and humans do poorly.
While we often think of computers as multi-tasking and able to handle
events simultaneously, this is a real-world example of contention for
physical resources, and this problem could probably be resolved within
the scheduler easily. For example, the logic to start jobs could add a
delay to consecutive jobs with an identical start time, as in:
foreach ( job at time "X" )
runjob
pause 30 s
done
The arbitrary delay of 30 seconds (in this example) is of no consequence
over the duration of a typical backup, but it has a great impact in
allowing the hardware to operate serially, so that bacula can properly
determine what media and drives are available when the next job with
the same scheduled start time actually begins running.
=> >
=>
=> I suspected something like that, but would ask out loud "if bacula runs
=> into a contention like that and there are other available volumes in the
=> requested pool, why doesn't it decide to use another volume instead of
=> blocking?"
Absolutely.
=>
=> It's also disappointing, because we've already pulled virtually all of
=> our scheduling outside of bacula into scripts because the logic seldom
=> works out for us. This may be another case of that. I'm surprised this
=> isn't a more common concern. What could be more run-of-the-mill than
My impression is that this is a common concern among bacula users. Perhaps
it's been difficult to determine the real problem, and that's why there
hasn't been a solution. Alternatively, there may be multiple conditions that
trigger the same behavior.
=> having a nightly incremental pool within an autochanger with multiple
=> drives?
=>
=> thanks!
=> Stephen
=>
=>
=> >>
=> >> If I do a status on the Director for instance and see the jobs for the
=> >> next day lined up in Scheduled jobs, they all have the same Volume listed.
=> >>
=> >> thanks,
=> >> Stephen
=> >
=> >
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
