On Monday 25 February 2008, Kern Sibbald wrote:
> > > 2. The current list of Run directives are essentially ANDed. That is
> > > Bacula will walk down the list and schedule all that apply.
> >
> > Minor problem here: In fact, Bacula "walks up" the list, in a way, at
> > least compared to the sequence of statements in the config file; in other
> > words: the list is read "bottom up".
>
> Ah, that is quite typical of my implementations (add to head of single
> linked list) when it "doesn't matter"
Your version is much cleaner and simpler, as long as sequence does not matter.
> > Should we consider reversing the logics in store_run(), i.e. append new
> > Run statements to the end of the list instead of prepending them?
>
> Yes, that is rather trivial to do -- no problem.
Patch (SVN) appended.
> Please give us an exact example of the Schedule directives with jobs you
> want ANDed and ones that you want ORed.
I can, of course, only speak for myself; other people's needs obviously
differ.
I never need ANDed schedules, as I don't (yet?) see requirements for jobs to
be executed twice. If there /is/ reason to execute the jobs twice - well, run
them with one minute difference, and they will be queued happily.
Sample scenarios I encounter:
Towers of hanoi with weekly full backups
----------------------------------------
Schedule {
Name = Hanoi3
Run = Level=Full Pool=PoolC w00 w04 w08 [...] mon at 08:00
Run = Level=Full Pool=PoolB w00 w02 w04 w06 w08 [...] mon at 08:00
Run = Level=Full Pool=PoolA mon at 08:00
}
Run backups to tapeset C in every 4th week (w04 w08 ...); tapeset B in every
second week (w00 w02 w04 w06 w08 ...); tapeset A in all other weeks.
Bacula should eliminate the runs to pool B in every fourth week by itself,
despite the fact that the second run is configured for w00 w02 w04 w06 w08
(...), and eliminate runs of A in all even weeks.
This scenario could be precalculated, but it was easier to solve it in
Bacula's scheduling mechanisms.
Monthly and weekly backups
--------------------------
Schedule {
Name = Foo1
Run = Level=Full Pool=MonthlyPool monthly 1 at 08:00
Run = Level=Incremental Pool=Incrementals mon at 08:00
}
Run full backups to MonthlyPool on the 1. day of each month; run incrementals
on mondays. Bacula should be able to eliminate the incremental job in case
the first day of each month is a monday.
This scenario cannot be precalculated (at least for a duration of more than
one year).
> Then I will have a better idea of
> what you are proposing. I am all for something simpler as long as the
> sytnax and semantics are clear.
My current plans/ideas certainly differ from what other people
want/require... :-/
As I said, my personal needs are restricted to ORed statements; adding an AND
semantics could - for me - be accomplished by adding a second, almost
identical Job statement, with an alternative schedule.
Having the flexibility of both versions in one type of statement (just with
the syntax you proposed) would of course be best for most people.
> > > 3. It is interesting that this comes just at this moment, because just
> > > tonight I was starting to work on the new "Duplicate Jobs" directive
> > > group for Jobs. That is a fairly comprehensive set of directives that
> > > tell Bacula how to deal with duplicate jobs.
> >
> > So your "Duplicate Jobs" directive is meant to deal with duplicate
> > executions of jobs, rather than with duplicate queuings, i.e. would
> > rather not prevent the jobs to be queued in the first place?
>
> In Bacula language, we usually speak of "scheduling" rather than queuing.
ACK. (The reason why I used a different term is that I understood that
scheduling refers to the "global" scheduling, i.e. the layout of all runs,
whereas queuing refers to the process of adding the execution of a certain
run of a schedule to the list of jobs to be executed. Of course, it's all a
matter of definition. I'll drop mine :)
> So, I think we should continue discussing possible modifications to the
> Schedule resource ...
Good :)
Thx
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ God is real, unless declared integer.
Index: src/dird/run_conf.c
===================================================================
--- src/dird/run_conf.c (revision 6485)
+++ src/dird/run_conf.c (working copy)
@@ -627,12 +627,19 @@
* in the schedule resource.
*/
if (pass == 2) {
+ RUN *tail = *run;
+
trun = (RUN *)malloc(sizeof(RUN));
memcpy(trun, &lrun, sizeof(RUN));
- if (*run) {
- trun->next = *run;
+ trun->next = NULL;
+
+ if (tail) {
+ while (tail->next) tail = tail->next;
+ tail->next = trun;
+ } else {
+ tail = trun;
+ *run = trun;
}
- *run = trun;
}
lc->options = options; /* restore scanner options */
-------------------------------------------------------------------------
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-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
