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
