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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
