On Friday 06 January 2006 01:02, David Jericho wrote:
> Hi all,
>
> I was trying to restore some data off a file archive written out to SAN
> storage. bacula-sd was crashing, and the command line tools would die with
> a segmentation fault, and would print something similar to following error:
>
> 05-Jan 05:40 bls: ERROR in record.c:494 Failed ASSERT: data_bytes <
> MAX_BLOCK_LENGTH Segmentation fault
>
> I recently upgraded to 1.38.2, from 1.36.1. When I first upgraded, I tested
> it fairly heavily, backing up multiple sites at a time, across multiple
> archives. Restores and backups worked error free during the tests.
>
> I then made a single change to all file and storage directors, being the
> setting of "Maximum Network Buffer Size = 524288". I have a large network
> spread across multiple countries, and large pipes between sites. As such I
> have TCP windows and other settings tuned to permit wire speed between any
> two servers on the network (in some cases, a 12 MB BDP). Increasing the
> buffer size resulted in an average 7 fold increase in backup throughput.
>
> Every one of the tape and file archives created since the change had errors
> in them. All archives written prior to the change of Maximum Network Buffer
> Size could be restored without error.
>
> I've looked through the source (in particular record.c) and I can see why.
> Debugging information from bls and friends showed me blocks with a 524288
> byte block size, all dated after the configuration change.
>
> I was in a hurry to restore the data though, so as an experiment I created
> the following patch (see line 494 of record.c for the ASSERT test):
>
> diff -ru bacula-1.38.2.orig/src/stored/block.h
> bacula-1.38.2/src/stored/block.h --- bacula-1.38.2.orig/src/stored/block.h
> 2005-01-29 22:39:02.000000000 +0000 +++
> bacula-1.38.2/src/stored/block.h 2006-01-05 06:25:15.000000000 +0000 @@
> -30,7 +30,7 @@
> #ifndef __BLOCK_H
> #define __BLOCK_H 1
>
> -#define MAX_BLOCK_LENGTH 500001 /* this is a sort of sanity check
> */ +#define MAX_BLOCK_LENGTH 1048576 /* this is a sort of sanity
> check */ #define DEFAULT_BLOCK_SIZE (512 * 126) /* 64,512 N.B. do not use
> 65,636 here */
>
> /* Block Header definitions. */
>
> A recompile, and a run of bextract, and the data came out of the archives
> (both tape and disk) just fine.
>
> I can figure out how and why this happened, but I'm not current enough with
> C to actually rewrite the code decently to fix the issue. I can forward the
> traceback and other bits and pieces if anyone is interested.
>
> Does the above patch potentially break anything else? Has anyone else come
> across this problem?
Your change is just fine. I'll probably make the same change here. As the
comment said, it was simply a sanity check to ensure that no really corrupt
data would pass through the system. I probably should either increase the
sanity check values to *much* higher numbers (there are several) or clearly
document them ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
