On Thu, Jan 28, 2010 at 02:21:08PM +0100, Kern Sibbald wrote:
> On Thursday 28 January 2010 13:55:15 Graham Keeling wrote:
> > On Mon, Jan 18, 2010 at 05:59:07PM +0100, Kern Sibbald wrote:
> > > Second "wrong" is that for VirtualFull, it is perfectly normal that the
> > > FileIndex values at a low level are out of order. I had forgetten about
> > > that. The FileIndex values at the record level are sequential and that
> > > is all that is important.
> > >
> > > After looking at this more, I see that there was sanity checking code in
> > > bls, bscan, and bextract that wanted to guarantee that the FI is
> > > sequential, which was OK before VirtualFull but should have been removed
> > > when I implemented VirtualFull.
> > >
> > > Those sanity checks are now removed, so the problems with bug #1410
> > > should now all be past history.
> >
> > ...
> >
> > > From my point of view, all is OK now. The File Index reports were a
> > > false alarm, and the crash was due to corrupted data on the Volume.
> > > Bacula now protects itself from the corrupted data and at least is able
> > > to read through your Volume.
> >
> > I have noticed in bacula-5.0.0 that you have removed the code that looks
> > like this...
> >
> > if (attr->file_index != rec->FileIndex) {
> > Emsg2(M_ERROR_TERM, 0, _("Record header file index %ld not equal
> > record index %ld\n"), rec->FileIndex, attr->file_index);
> > }
> >
> > ...from:
> >
> > src/stored/bextract.c
> > src/stored/bls.c
> > src/stored/bscan.c
> >
> > But, it still exists in src/filed/verify_vol.c.
> >
> > I have a user who is trying to do a restore that includes a VirtualFull
> > volume, and he is getting this error and is unable to restore any files:
> >
> > bacula-dir: clientx-fd: ro.nu-restore.2010-01-28_12.06.38_37 Fatal error:
> > Record header file index 18432 not equal record index 18778 bacula-dir:
> > servery-sd-9103 Error: bsock.c:518 Read error from
> > client:194.168.151.5:36643: ERR=Connection reset by peer
> >
> >
> > Shouldn't the code also be removed from src/filed/verify_vol.c?
>
> Yes, it should also be removed there as well. The code was a reasonable
> sanity check until VirtualFull was implemented. Most all VirtualFull backups
> will have file indexes that are not incremental, so any such insanity check
> becomes a "bug".
>
> Thanks for pointing this out.
No problem.
Also, can you tell me where the change was that prevents the storage daemon
crashing on reading my backup-0009?
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
