Re: [Bacula-devel] Bug #1410 - Broken VirtualFull volumes and?bacula-sd segfault

[Kern S. <ke...@si...>]

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.

Best regards,

Kern

>
>
> ---------------------------------------------------------------------------
>--- 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
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacula-devel