[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bacula-bugs
Subject:    [Bacula-bugs] [bacula 0001667]: Block values in jobmedia record may
From:       Mantis Bug Tracker <nobody () baculabugs ! unixathome ! org>
Date:       2010-11-22 21:12:25
Message-ID: d96b43bc7fb4b484cc225e21d3ccb708
[Download RAW message or body]


The following issue has been SUBMITTED. 
====================================================================== 
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 UTC
Last Modified:              2010-11-22 21:12 UTC
====================================================================== 
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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-22 21:12 craigmiskell   New Issue                                    
======================================================================


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Bacula-bugs mailing list
Bacula-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-bugs


[prev in list] [next in list] [prev in thread] [next in thread]