From: Kern S. <ke...@si...> - 2003-12-30 10:57:45
|
On Tue, 2003-12-30 at 02:49, Nic Bellamy wrote: > On Wed, 2003-12-24 at 23:29, Kern Sibbald wrote: > > Hello Nic, > > > > On Tue, 2003-12-23 at 23:27, Nic Bellamy wrote: > > > Could I get you to double check the switch () statements in the > > > job_check_maxwaittime and job_check_maxruntime functions in > > > src/dird/job.c? I'm reasonably sure I've got them right, but you're in a > > > better position to know. > > > > I've taken another look at these switch() statements. I'm not 100% sure > > how you are distinguishing between maxwaittime and maxruntime. > > Logically, maxwaittime would be the total about of time waited, but from > > the code, it seems to me that the time is the total runtime, and the > > kill is triggered if Bacula finds itself in a wait state. Note, the > > wait/no wait state can frequently change. > > That was something that I needed to address and had forgotten about > between writing the code and sending it off to you (I broke my golden > rule of "write everything down, because I *will* forget it otherwise"). I have the same problem -- my solution is to have a kernstodo in each project and to "force" myself to make note when the problems/ideas first appear. > > > It seems to me that we may need to limit the maxwaittime cancel to jobs > > that are blocked in the scheduling queue, and jobs where the daemon wait > > time exceeds the maxruntime value. The daemon wait time is something > > that the SD calculates, but it need to be sent back to the DIR to be > > able to properly implement the "daemon wait time". > > What I want MaxWaitTime to do is cancel jobs where the SD has been > waiting for a media mount for longer than the MaxWaitTime value. It > currently doesn't quite do this (it's basically like maxruntime but only > cancels if the job is blocked on media), and I had meant to fix it. Is > there any way to get the SD mount wait time from within the director or > will we need to make a way? This is all very reasonable, it is just what I would like to do also. Current the SD does accumulate the wait time in order to try to make a good estimate of the throughput. It will just be a matter of having it return the value from time to time, or on request to the Director -- or the other possibility is to pass the times to the SD when the job is open, then let the watchdog thread in the SD do the cancel locally. As 1.33 progresses, I'll be looking into this again because I've planned to add Volume read/write usage time, where it will also need to eliminate wait time. Question: Were destructor_thread_timer() and destructor_child_timer() ever actually used, or were they just planned for the timer cleanup? I ask, because I had to #ifdef them out to avoid compiler warnings in compiling lib/timers.c > > On the subject of testing I'm currently stuck, as my DLT2000 crapped > itself recently - it's long out of warranty, and I don't have the means > to replace it quite yet. :-/ > > On the offchance, does anyone have a spare DDS-3 drive they'd sell to me > for a reasonable price? > > Cheers, > Nic. |