From: Mantis B. T. <no...@bu...> - 2010-12-30 11:32:28
|
Issue 0001667 is now monitored by user thrasherbcn. ====================================================================== http://bugs.bacula.org/view.php?id=1667 ====================================================================== Reported By: craigmiskell Assigned To: ====================================================================== Project: bacula Issue ID: 1667 Category: Director Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-11-22 21:12 GMT Last Modified: 2010-12-30 11:32 GMT ====================================================================== Summary: Block values in jobmedia record may be incorrect Description: There's something not quite right about the jobmedia records created by the backup jobs, as compared to the information returned by bscan. Specifically, after a small job has run: bacula=# select * from jobmedia where jobid=2984; jobmediaid | jobid | mediaid | firstindex | lastindex | startfile | endfile | startblock | endblock | volindex ------------+-------+---------+------------+-----------+-----------+---------+------------+----------+---------- 62345 | 2984 | 49 | 1 | 7430 | 0 | 0 | 1 | 83219 | 1 62346 | 2984 | 49 | 7430 | 12878 | 1 | 1 | 0 | 83219 | 2 62347 | 2984 | 49 | 12878 | 21034 | 2 | 2 | 0 | 83219 | 3 62348 | 2984 | 49 | 21034 | 28886 | 3 | 3 | 0 | 83219 | 4 62349 | 2984 | 49 | 28886 | 41161 | 4 | 4 | 0 | 83219 | 5 62350 | 2984 | 49 | 41161 | 103539 | 5 | 5 | 0 | 74973 | 6 Compare this to the output from bscan with the -r option (snippet of the logs as it crosses the file boundary on the tape: "Block" was added by myself for other debugging): bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7427 Stream=2 Block=83219 len=65536 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7427 Stream=2 Block=83220 len=32768 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7427 Stream=3 Block=83220 len=16 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7428 Stream=1 Block=83220 len=110 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7428 Stream=2 Block=83220 len=512 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7428 Stream=3 Block=83220 len=16 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7429 Stream=1 Block=83220 len=114 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7429 Stream=2 Block=83220 len=4096 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7429 Stream=3 Block=83220 len=16 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7430 Stream=1 Block=83220 len=117 bscan: bscan.c:472 Record: SessId=13 SessTim=1290023781 FileIndex=7430 Stream=2 Block=1 len=65536 Note that there is file data in block 83220, but the jobmedia record only mentions up to block 83219. This inconsistency doesn't affect restores in this case, because the file spans the mediafiles; but if file 7430 ended within block 83220 though, I thing there might be some fallout. I can't immediately see how to force this to happen though (not trivially, other than running various backups on test files until it the sizes cause it to happen). Possibly related: startblock is also 0 for all but the first record, but as seen on bscan, there is no block 0. Does this matter? Also, in some cases, the startblock found is 2; this is as given to record_cb in bscan.c. Again, is this an issue? I'm not 100% sure this is an issue, but having noticed it (while doing bug 1666), I figure it worth raising so that someone much more familiar with the internals of bacula can assess. Steps to Reproduce: Run a backup Look at the jobmedia records Run bscan -r on the media, observe inconsistencies in the block numbers reported by bscan compared to the original jobmedia records. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2010-11-22 21:12 craigmiskell New Issue 2010-11-23 08:51 mnalis Issue Monitored: mnalis 2010-12-30 11:32 thrasherbcn Issue Monitored: thrasherbcn ====================================================================== |