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,VolRetention,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastWritten,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Enabled,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolReadTime,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,VolRetention,VolUseDuration,MaxVolJobs,MaxVolFiles,Recycle,Slot,FirstWritten,LastWritten,InChanger,EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,Enabled,LocationId,RecycleCount,InitialWrite,ScratchPoolId,RecyclePoolId,VolReadTime,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
