I can this this feature being useful to me when out of town and Bacula needs a new tape, but doesn't get one for several days.
On 4 Nov 2007 at 19:15, Kern Sibbald wrote: > On Sunday 04 November 2007 18:31, David Boyes wrote: > > > 1. Allow Duplicate Jobs = Yes | No | Higher (Yes) > > > > Looks OK. One question: if a lower level job is running, and a higher > > level job attempts to start, does this imply that the lower level job is > > cancelled, and the higher level one is run instead? I think this is > > desirable behavior if possible (or maybe it might require an additional > > option of Supercede for this directive to enable this behavior). > > I hadn't planned to cancel the lower priority job, but I had thought about > the > possibility. However, now that you mention it, I think we need some keyword > to do this. Any suggestions? -- CancelLower, HigherWithCancel ? Priority is mentioned above. Do you mean Priority (as in 1, 5, 10), or do you mean Level (as in Inc, Diff, Full)? I think you mean Level. I point out other references to Priority below in case Priority is meant. In which case, CancelLowerLevel is more precise. For what it's worth, the term Single Instance also can to mind... Now that we're talking about Priority, will Priority have any role in these directives? > By the way, if a lower priority job is scheduled, but not running, I was > planning to cancel it. A new keyword would certainly clarify what should > happen. Priority? Or Level? I agree that in any case, we would never cancel a running job with this directive. > > > 2. Duplicate Job Interval = <time-interval> (0) > > > > The semantics look fine, but a usability suggestion: > > > > Since you're really setting a proximity guard interval, it might be > > easier to understand for the end user if you used Duplicate Job > > Proximity rather than Interval. That would give the implication of "no > > closer than" that I think you want, and it might translate better. Another way to look at Duplicate Job Proximity is "don't run this job again if it has been run within the past 'interval'", which is getting into the domain of the Schedule resource. We will need to document that one carefully. > Yes, I was thinking of calling it Duplicate Job Delay, but that was > confusing. > I think "Duplicate Job Proximity" will be the most clear. Thanks. Going into synonym mode, here are some I thought close to this, in case they sound better collision, nearness, adjacency, zone, neighborhood, range, region I still think Proximity is best. > Another point is that I could do a lot of this in the scheduler -- i.e. just > not run jobs if one was already running, but I think I will actually "start" > the job, print a message, then cancel it if it is of equal or lower priority Priority? Or Level? > (i.e. not supposed to run). That way, there will be some record. We might > even want to invent a new message class (for example: AutoCancelled) so that > the job output from such jobs could be sent elsewhere (i.e. down the bit > bucket if one wants). I think keeping some record is a good idea. > > > PS: I think the default for Allow Duplicate Jobs should be Higher, but > > > that > > > would change current behavior ... > > > > I agree with you. It's dumb to do an incremental followed immediately by > > a full backup if they're going to dump the same data in roughly the same > > timeframe. > > Yes, but I always hesitate to make non-compatible changes ... Agreed. -- Dan Langille - http://www.langille.org/ Available for hire: http://www.freebsddiary.org/dan_langille.php ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
