Hello, wt., 3 gru 2019 o 16:04 Martin Simmons <mar...@lispworks.com> napisał(a):
> >>>>> On Tue, 3 Dec 2019 15:15:53 +0100, Radosław Korzeniewski said: > > > > Hello, > > > > wt., 3 gru 2019 o 14:27 Martin Simmons <mar...@lispworks.com> > napisał(a): > > > > > Is the current timing useful for some other situation? > > > > > > > I do not understand your question. > > I'm trying to understand why it is implemented like it is. > I don't know, you have to as Kern. > I hope we agree that jobs have a scheduled time and a start time. The > start > time can be much later than the scheduled time, for example if the job > priority is specified and a job with a smaller priority is running. > I think we have a small misunderstanding here. In Bacula from a technical point of view scheduled time means: I already prepared all job parameters and put this product on the queue ready for run. Then a start time is when a scheduler picks it from the queue and attach it to execution thread. You can have a lag between scheduled time and start time because the job has to wait in the queue. It could wait a few cpu ticks when all is ready to go or a few hours when other resources are busy or other priority jobs not finished yet. > A copy job currently chooses the jobs to be copied at the scheduled > time(A), > Yes. > but Phil and myself think that it should choose the jobs to be copied at > the > start time(B). I fully understand what you want and I do not deny it. > Can you explain if (A) is ever better than (B) for the user? > Both have pros/cons depends on what is your backup policy and no policy is overall better. I prefer a cyclic copy (replication) job which allows me to maintain a shortest delay between backup and copy and is easier to operate and configure. In this case when jobs are not ready to copy at this point in time then it will be in a few moments later, so the next copy job can handle it. I never use priorities for the jobs as the current scheduling procedure can starve my whole backup system which I do not accept. I encourage people not to use it too. > Please don't just say "(A) is better because it is implemented like that" > because I want to focus on making Bacula more useful for a user. > No, absolutely not. Why did you say that? It hurts. The problem is that the current behavior is not a bug and in all my comments I want to show you how it is working and how it was designed. Only that. You can change the design or ask for a design change. Let's take a look at fread(3) which return the following value: *(...)* *If an error occurs, or the end of the file is reached, the return value is a short item count (or zero).* *(...)* So this function was designed that it expresses an error or end of file in the same way. Someone could argue that it is a bug as it should clearly show when it is end of file and when it is an error. I hope you understand the point. > > It seems like a bug to me too. :) > To continue your analogy, it is like the > > > restaurant forcing you to choose a dish when you book the table, before > > > you've > > > seen the menu of the day. > > > > > > > No, absolutely not. When you execute the copy job then all required data > is > > available and copy jobs simply start, so the menu is available when you > > book a table. > > But when you go to the restaurant then an admin stop you entering the > room > > and force you wait until the next day when menu changed - so it is not a > > surprise. > > Admin should not prevent a copy job from executing. This is the main > issue > > here in the code which is currently available. > > > > If you think it should work differently then you have to implement a > > different kind of mechanism. And as I understand Heitor's answer the > > solution is to link copy job with source job using Run=... directive. > Then > > your copy job will be executed when your source job finish. > > The job priority is an existing mechanism that is used to delay the start > time > of a job for many related situations. No. The priority mechanism is to prohibit concurrent job execution for jobs of different priority. It is not a synchronization mechanism, there is no "related situations". > It doesn't work for copy jobs because > Bacula chooses the jobs to be copied at the scheduled time. > Job priority mechanism works perfectly with copy jobs. Unfortunate you expect a different behavior of this mechanism which was never implemented. This is a main issue. > My point is that for copy jobs: > > - At the scheduled time, the function do_mac_init chooses the jobid(s) to > copy. > > - At the start time, the function do_mac copies the chosen jobid. > > Contrast this with verify jobs: > > - At the scheduled time, the function do_verify_init does not choose the > jobid > to verify. > > - At the start time, the function do_verify chooses the jobid to verify. > > Is this different by design or was it just implemented like that? > Could you please prepare a patch which implement this behavior in a that way? On the other hand: - as I understand the main problem discussed here was resolved at least in Bacula Enterprise where you can create "linked job execution", so you can start copy job right after the main job terminates, right? - all you need for your copy job policy with priorities is to create a job which just execute a copy job at the right time best regards -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
