>>>>> On Wed, 11 Dec 2019 09:32:51 +0100, Radosław Korzeniewski said: > > 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.
Apologies, I was getting frustrated because I didn't see any evidence (e.g. in the documentation) that it was designed to work that way. > 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. Yes, I understand the difference between a design and an implementation. It is also useful to note that an implementation can sometimes become the design by accident or inertia! > > > > 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". I have already mentioned a related situation: a VolumeToCatalog verify job, which must run after the corresponding backup job. The priority can be used to enforce this "must run after" requirement, so that makes it a synchronization mechanism. > > > > 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. True -- it all depends on whether it was designed like that or if someone implemented it like that without considering it. > > > > 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? I think it is best to wait until the design is agreed, otherwise the patch will just be rejected. > 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? It's good to hear that Bacula Enterprise has a solution, but I don't know about it. > - 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 Yes, but as Phil mentioned, it is difficult to choose the right time. __Martin _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
