Bacula-users

Re: [Bacula-users] Multi-cores compression

2012-03-05 10:36:51
Subject: Re: [Bacula-users] Multi-cores compression
From: Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>
To: Alex Crow <acrow AT integrafin.co DOT uk>, bacula-users <Bacula-users AT lists.sourceforge DOT net>
Date: Mon, 05 Mar 2012 15:46:30 +0000
On 05/03/12 15:08, Alex Crow wrote:
> On 05/03/12 14:45, Alan Brown wrote:
>> On 05/03/12 14:24, Gael Guilmin wrote:
>>> To gain space on the LT0.
>> Don't bother.
>>
>> 1: Compression maxes out at about 30MB/s
>>
>> 2: LTO has inbuilt hardware compression which is "good enough" and a
>> _LOT_ faster than any CPU you can throw at the task.
>>
>> The _only_ use for compression is on slow WAN links and when writing to
>> disk - and for the latter I'd consider using compressing FSes such as
>> ZFS in preference to using Bacula compression.
>>
>
> What about when you are encrypting? You have to do the compression in
> Bacula as once you've encrypted the data it can no longer be compressed
> by the drive (eg for LTO < LTO4 where the drive cannot encrypt.)

Encryption programs generally compress as well in order to increase 
entropy - so any external compression routines will just make things 
slower for no gain.

As soon as you're doing things which slow down the data flow you have to 
put up with painfully slow (for me) throughput and you _MUST_ use disk 
spooling to prevent tape drive shoeshining(*).

Multithreading might help but it's generally only available for 
block-based compression algorithms such as bzip2 (multithreaded 
decompression isn't available for Pbzip) and that's not going to help 
much on a stream-based setup such as bacula without major rewrites.

Encrypted setups are fine, but bear in mind that 2% of data losses are 
down to loss of keys - and while a damaged enencrypted backup might be 
partially recoverable its' highly likely that damage on an encrypted one 
will result in 100% loss.


(*) Anything which results in uncompressed data being presented to the 
tape drive at a minimum throughput of less than 200MB/s will result in 
shoeshining (even though the actual tape rate is less than this, if the 
data is compressaable it needs to feed the drive fast enough to avoid 
the tape stopping or slowing down. Highly compressable data may require 
much faster minimum throughputs.) Even slow spool disks are a problem. 
You can test this by measuring throughput to /dev/null




------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users