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.
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 ... " 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,VolErrors, >>VolWrites,MaxVolBytes,VolCapacityBytes,MediaType,VolStatus,PoolId,VolRetenti >>on,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastWritt >>en,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Enabled >>,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolReadTim >>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,VolErrors, >>VolWrites,MaxVolBytes,VolCapacityBytes,MediaType,VolStatus,PoolId,VolRetenti >>on,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastWritt >>en,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Enabled >>,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolReadTim >>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
