Thanks. I've now added code to keep the Schedule list in the order the user
gave it. My implementation is slightly different from yours since I followed
more closely the style I had used for other resources that need to be kept
proper order.
Thanks for pointing out the problem and the fix.
Best regards,
Kern
On Monday 25 February 2008 12:03:21 Bastian Friedrich wrote:
> 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
-------------------------------------------------------------------------
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-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
