On Thursday 01 November 2007 19:43, GDS.Marshall wrote: > Hello, > > Thank you, I will certainly take your advice and take the approach you > have suggested. Wife permitting, I will work on it over the weekend.
OK, thanks. > > As an addition, what were you thinking of when you wrote > " > > >> > I > >> > assume you are trying to make as if the job is actually run in the > >> > future, which would be nice ... That was the substance of your bug report. Bacula currently gives information on what Volumes would be mounted at the moment the status command is issued, when it *should* be giving information on what Volumes would be mounted in the future when the job is actually run. Kern > > " > > Regards, > > Spencer > > On Thu, 1 November, 2007 6:05 pm, Kern Sibbald wrote: > > OK, I see what you are trying to do. > > > > I'd suggest taking a slightly different approach, because you will get > > into a > > *lot* of trouble trying to do time comparisons in SQL (each engine does > > it differently). > > > > Modify the calling sequence of find_next_volume_for_append to include a > > new > > argument. The argument would be "utime_t when". In all calls it would > > be set to time(NULL) except in the call from ua_status, where you set it > > to the > > time the job is supposed to run. This argument would then be passed to > > the > > subroutine has_volume_expired(), which is in next_vol.c, and that > > subroutine > > will use that time in place of the variable "now". > > > > In catreq.c, which calls both subroutines, you just need to ensure you > > only > > call time(NULL) once to keep OS overhead down. > > > > Note, virtually all subroutine prototypes are in protos.h in each > > directory. > > > > Hopefully that makes sense to you, and it should minimize "dangerous" > > changes > > (almost any SQL change is "dangerous" -- i.e. prone to failing). There > > may > > be a bit more to it, but that is how I would start ... > > > > Best regards, > > > > Kern > > > > On Thursday 01 November 2007 18:42, GDS.Marshall wrote: > >> On Thu, 1 November, 2007 4:19 pm, Kern Sibbald wrote: > >> > Hello, > >> > > >> > On Thursday 01 November 2007 16:22, GDS.Marshall wrote: > >> >> I am working on a patch for "status dir" and expired volumes. I am > >> > >> not > >> > >> >> sure if this is the right place to ask this kind of question or if I > >> > >> am > >> > >> >> just going to put peoples backs up. I hope the latter is not the > >> > >> case. > >> > >> > This is the correct place, and I doubt that anyone will be upset > >> > certainly not > >> > me. > >> > > >> >> >From debugging, I believe I need to modify find_next_vol_for_append > >> > >> (I > >> > >> >> can > >> >> > >> >> do this bit). I have determined, that in ua_status.c line 412 (ps > >> > >> the > >> > >> >> debugging is really good and helpful thank you) sp->runtime contains > >> > >> the > >> > >> >> time of the next run, jcr->run_time is 0 and jcr->sched_time is the > >> > >> time > >> > >> >> now. What do I screw up if anything by updating jcr->sched_time with > >> >> the > >> >> sp->runtime value just prior to ua_status.c line 412? This would > >> > >> allow > >> > >> >> me > >> >> to use jcr->sched_time in the sql. > >> > > >> > Modifying jcr->sched_time is possible to cause problems someplace. > >> > >> Can > >> > >> > you > >> > explain why you want to change it and for which SQL statement? > >> > >> Certainly, as I wrote, I have done some debugging, an extract is below, > >> to > >> save you reading it, and to make sure I have understood correctly, I > >> will > >> explain. At present, find_next_vol_for_append runs the following SQL > >> SELECT > >> MediaId,VolumeName,VolJobs,VolFiles,VolBlocks,VolBytes,VolMounts,VolErro > >>rs, > >> VolWrites,MaxVolBytes,VolCapacityBytes,MediaType,VolStatus,PoolId,VolRet > >>enti > >> on,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastW > >>ritt > >> en,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Ena > >>bled > >> ,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolRea > >>dTim e,VolWriteTime FROM Media WHERE PoolId=5 AND MediaType='DLT-V4' AND > >> Enabled=1 AND VolStatus='Append' AND InChanger=1 AND StorageId=2 ORDER > >> BY > >> LastWritten IS NULL,LastWritten DESC,MediaId LIMIT 1 > >> > >> This pulls back VolumeName CNI900, which right this minute, is correct, > >> if > >> I ran a job now, it would append to that VolumeName, but when the job > >> comes to run in a few hours time, the VolUseDuration will have caused > >> the > >> Media to for want of a better word, expire, and it will use a different > >> media. If I add a clause > >> AND > >> TIMESTAMPDIFF(SECOND,ADDDATE(FirstWritten,(VolUseDuration/86400)),....) > >> > >> 0 > >> change .... for the time the job is to run at, should pull back an > >> 'Append' VolumeName which really is appendable at the time. > >> > >> > >> fileserver-dir: ua_status.c:404-0 Using pool=Daily^M > >> fileserver-dir: ua_status.c:412-0 call find_next_volume_for_append^M > >> fileserver-dir: ua_status.c:413-0 spencer call > >> find_next_volume_for_append > >> sp->runtime 1193983500^M > >> fileserver-dir: ua_status.c:414-0 spencer call > >> find_next_volume_for_append > >> jcr->run_time 0^M > >> fileserver-dir: ua_status.c:415-0 spencer call > >> find_next_volume_for_append > >> jcr->sched_time 1193922889^M > >> fileserver-dir: next_vol.c:61-0 find_next_vol_for_append: JobId=0 > >> PoolId=5, MediaType=DLT-V4^M > >> fileserver-dir: sql_find.c:323-0 fnextvol=SELECT > >> MediaId,VolumeName,VolJobs,VolFiles,VolBlocks,VolBytes,VolMounts,VolErro > >>rs, > >> VolWrites,MaxVolBytes,VolCapacityBytes,MediaType,VolStatus,PoolId,VolRet > >>enti > >> on,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastW > >>ritt > >> en,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Ena > >>bled > >> ,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolRea > >>dTim e,VolWriteTime FROM Media WHERE PoolId=5 AND MediaType='DLT-V4' AND > >> Enabled=1 AND VolStatus='Append' AND InChanger=1 AND StorageId=2 ORDER > >> BY > >> LastWritten IS NULL,LastWritten DESC,MediaId LIMIT 1^M > >> fileserver-dir: sql_find.c:400-0 Rtn numrows=1^M > >> > >> > That might > >> > help tie down what would be the right way to approach it or at least > >> > allow me > >> > to verify that modifying sched_time in this case will not be a > >> > >> problem. > >> > >> > I > >> > assume you are trying to make as if the job is actually run in the > >> > future, which would be nice ... > >> > >> Yes correct, I am trying to solve my own bug report :) 0000978 > >> Initially > >> I was just looking for a "status dir" to pick the correct media when the > >> VolUseDuration is exceeded and VolStatus='Append'. > >> > >> > By the way, please take a look at www.bacula.org -> FSFE License, fill > >> > out two > >> > copies, send them in, and let me know by email when you have done so. > >> > That > >> > speeds up accepting any possible patch you would submit. > >> > >> Okay, will do. > >> > >> > Regards, > >> > > >> > Kern > >> > >> Regards, > >> > >> Spencer ------------------------------------------------------------------------- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
