Hello,

I've run some tests. The combination of sparse=yes and autoxflate is generally 
broken
even with a small non-sparse testfile, I've added a comment at
http://bugs.bareos.org/view.php?id=694

So logically, it's also implicitly broken when adding Python Plugins.

Without sparse=yes, the combination of autoxflate and Python Plugins works 
correctly.

However, using sparse=yes with Python Plugins but without autoxflate also has 
an issue,
but that only hits with blocks of zeros larger than 64K in the data stream.

Conclusion: These are two unrelated issues. Don't use sparse=yes together with 
autoxflate
or Python Plugins.

If it's possible to access the sparse setting from the Fileset information 
within a Python Plugin,
and the plugin can't handle sparse properly, it should fail the job with an 
appropriate
error.

Regards,

Stephan

On 02/13/2017 11:06 AM, Maik Aussendorf wrote:
> Hello,,
> 
> you are both right: I could reproduce the behavior  with autoxflate +
> sparse = yes in the FileSet options just as in
> 
> http://bugs.bareos.org/view.php?id=694
> 
> Kjetil, please check, if you have Sparse=yes, turn it off and test it again.
> 
> Regards
> Maik
> 
> 
> Am 09.02.2017 um 22:10 schrieb Bruno Friedmann:
>> On jeudi, 9 février 2017 17.59:49 h CET Kjetil Torgrim Homme wrote:
>>> Kjetil Torgrim Homme <[email protected]> writes:
>>>> thank you for your hints!  I'm trying to dig further...
>>> ok.  I changed xtrabackup to be a wrapper script which ran tee to save a
>>> copy of stdout to a file.  that copy is valid for restore.
>>>
>>> I have done two restores of the same job to a client without the plugin,
>>> the md5sum is the same.  IOW, the corruption doesn't happen (randomly)
>>> during restore.
>>>
>>> the tee'd off file and the restored file differ in many places.  the
>>> first difference is at byte 65527.
>>>
>>>    OFFSET  ORIGINAL DUMP              RESTORED DUMP
>>>    0xFFF6  00 00                   -> ff f8
>>>   0x1FFED  00 00 00                -> 01 ff f0
>>>   0x2FFE0  29 24 db 23 b3 22 85 21 -> 00 00 00 00 00 02 ff e8
>>>   0x3FFDD  00 00 00                -> 03 ff e0
>>> ... and so on for every 64 KiB.
>>>
>>> one thing I should mention is that I have enabled the autoxflate-sd
>>> plugin.  I wonder if that can corrupt data (it definitely is in the
>>> position to do so...)  unfortunately I rarely have a window where no
>>> jobs are running so that I can restart the SD.  I'll keep you posted
>>> when I get the chance to try it out.
>> Could be also related to this report
>> http://bugs.bareos.org/view.php?id=694
>>
>> Seems your affected by the same problem.
>>
> 


-- 
  Stephan Dühr                              [email protected]
  Bareos GmbH & Co. KG                      Phone: +49 221-630693-90
  http://www.bareos.com

  Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
  Komplementär: Bareos Verwaltungs-GmbH
  Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to