You:
> On Aug 13, 2010, at 4:10 AM, Dietz Pröpper wrote:
> > 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.
> 
> Those problems affect software compression, too.

Hmm, I can't reproduce them with gzip on the data in question.
> 
> LTO takes steps to ameliorate the effects of pre-compressed/high entropy
> input data by allowing an output block to be prefixed as being
> uncompressed.  So, if input data would cause a block to grow due to
> compression, it can output the original input itself, with the block
> prefixed, meaning only a very tiny percentage increase in tape usage
> for stretches of high-entropy input.

Ack. I read the link after posting ;-). LTO should behave fine in that 
respect.

> > 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.
> 
> I agree with point 2, however I believe the trend has been to move
> towards using algorithms defined and documented in published standards
> for the very reasons you state.

At least LTO should be fine here, too.

------------------------------------------------------------------------------
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