Sorry, my earlier message was incomplete :)
Hello all,
Looking at the 7.0.5 version code, It seems that the part that checks the
checksum error (block_util.c, unser_block_header function) detects the
checksum error but does not return the non zero exit code, as occurs in
other parts of the code, for other errors found on unserializing the header
block.
block->read_errors++;
if (!forge_on) {
return false;
}
Maybe this "if (!forge_on)" should not be there. In the case it was just to
let the code:
block->read_errors++;
return false;
I´m not sure if this is the wanted behavior or not. I will try to run some
tests to verify this.
Best regards,
Ana
On Wed, Aug 12, 2015 at 1:43 PM, Josip Deanovic <djosip+n...@linuxpages.net>
wrote:
> On Wednesday 2015-08-12 16:17:42 Andrey Tataranovich wrote:
> > On Tue, 11 Aug 2015 15:47:40 +0100
> >
> > Martin Simmons <mar...@lispworks.com> wrote:
> > > You could use bls -j with the volume file to scan the whole volume.
> >
> > I'm upset with bls behavior - it does not return non zero exit code
> > on error and output error messages to stdout instead of stderr.
> >
> > # bls -j /bacula/backup/Libvirt-0177; echo $?
> > bls: butil.c:287 Using device: "/bacula/backup" for reading.
> > 12-Aug 16:11 bls JobId 0: Ready to read from volume "Libvirt-0177" on
> > device "FileStorage" (/bacula/backup). Volume Record: File:blk=0:196
> > SessId=6 SessTime=1438429819 JobId=0 DataLen=161 Begin Job Session
> > Record: File:blk=0:64708 SessId=6 SessTime=1438429819 JobId=7462
> > Job=Backup_Win2k3.2015-08-02_22.00.00_20 Date=02-Aug-2015 22:18:05
> > Level=F Type=B 12-Aug 16:12 bls JobId 0: Error: block.c:318 Volume data
> > error at 1:1073721369! Block checksum mismatch in block=83221
> > len=64512: calc=91787392 blk=161ef20e
> > 0
> >
> > Is it fixed in newer versions? Currently I'm using 5.2.6.
>
>
> Hi Andrey,
>
>
> I am using bacula 7.0.5 and I have tried to emulate the damaged backup
> volume but I have failed to get the Block checksum mismatch error.
>
> Since in my case bls continues to work up until the end of the volume
> it returns 0 which might be fine depending on the developer's decision
> whether the operation should be considered successful or not.
>
> Im my tests all the messages, including Error messages are sent to the
> stdout instead of the stderr. Again, there might be some logic behind
> it but it might be a good idea to send Error messages to the stderr.
>
> In your case I believe that the return value should be 1 as bls
> obviously encountered a fatal error and exited but since I failed to
> reproduce the problem you are experiencing I cannot confirm that is has
> been fixed without looking into the code.
>
>
> --
> Josip Deanovic
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
