Rory Campbell-Lange:
> On 12/08/10, Mike Hanby (mhanby AT uab DOT edu) wrote:
> > I'm curious whether others with the PV-124T with LTO4 are using
> > hardware or software compression.
> > 
> > I am testing a new Bacula deployment with one of these autoloaders /
> > drives and haven't found a good suggestion as to which type of
> > compression to go with.
> 
> My setup is a single machine with attached storage and tape drive.
> 
> I think it depends on how big your backups are and what sort of
> compression you are looking for. On my fast server (8 core Xeon
> E5520/2267MHz) it halves the speed of the the read off disk when using
> software compression (it uses most of the CPU on one core to do the
> compression).
> 
> This was a useful mailing list thread:
> http://old.nabble.com/LTO:-hardware-vs.-software-compression-td15609768.
> html
> 
> I have hardware compression on and I get around 100MB/s throughput to
> the tape device on a SAS card, and manage about 1.1TB on an LT04 tap.
> 
> I'd be interested to hear other thoughts on this.

IMHO there are two problems with hardware compression:
1. Data mix: The compression algorithms tend to work quite well on 
compressable stuff, but can't cope very well with precompressed stuff, i.e. 
encrypted data or media files. On an old DLT drive (but modern hardware 
should perform in a similar fashion), I get around 7MB/s with "normal" data 
and around 3MB/s with precrompessed stuff. The raw tape write rate is 
somewhere around 4MB/s. And even worse - due to the fact that the 
compression blurs precompressed data, it also takes noticeable more tape 
space.
2. Vendors: I've seen it more than once that tape vendors managed to break 
their own compression, which means that a replacement tape drive two years 
younger than it's predecessor can no longer read the compressed tape. 
Compatibility between vendors, the same.
So, if the compression algorithm is not defined in the tape drive's 
standard then it's no good idea to even think about using the tape's 
hardware compression.

cheers,
        Dietz

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users