On Wednesday 26 March 2008 14:12:50 Tom Ivar Helbekkmo wrote: > There's definitely something fishy in the recording of start and > end blocks in the JOBMEDIA table. This is a snip from last night's > incremental run (still using 2.2.8 plus the four published patches, plus > my posted fix for the jobmedia patch): > > jobmediaid | jobid | mediaid | firstindex | lastindex | startfile | > endfile | startblock | endblock > ------------+-------+---------+------------+-----------+-----------+------- >--+------------+---------- 119 | 26 | 3 | 1 | 53 | > 31 | 31 | 0 | 32 120 | 27 | 3 | > 1 | 83 | 31 | 31 | 0 | 242 121 | 28 | > 3 | 1 | 239 | 31 | 31 | 0 | > 5683 > > Since I'm using spooling, those jobs should not be interspersed on > tape. Still, at least it seems the error is in including too many > blocks in the set that a job's files occupies, so if I understand > correctly, it shouldn't cause any restore problems. :)
It should not create any problems restoring. However, I don't understand why they all start at zero. I suspect that has something to do with the fact that you are using spooling, and they record the start block early in the game at the beginning of the spooling and the code is not intelligent enough to wait until the very first block is actually written to *tape*. This inefficiency has probably existed since day one, but I will check it, and in any case, will put it on my priority list to fix. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel