Howdy, 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
Author: Rory Campbell-Lange <rory AT campbell-lange DOT net>
Date: Fri, 13 Aug 2010 00:23:35 +0100
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 E552
Author: John Drescher <drescherjm AT gmail DOT com>
Date: Thu, 12 Aug 2010 19:34:18 -0400
Never use software compression on an LTO drive. Hardware compression much faster. John -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challeng
Author: Craig White <craigwhite AT azapple DOT com>
Date: Thu, 12 Aug 2010 16:39:52 -0700
-- use hardware compression http://en.wikipedia.org/wiki/Linear_Tape-Open read the section on compression Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Fri, 13 Aug 2010 10:10:27 +0200
Rory Campbell-Lange: 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 precom
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Fri, 13 Aug 2010 10:12:47 +0200
John Drescher: I get around 100mb/s with gzip -1 ;-). -- 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
Author: John Drescher <drescherjm AT gmail DOT com>
Date: Fri, 13 Aug 2010 08:23:32 -0400
On Fri, Aug 13, 2010 at 4:12 AM, Dietz Pröpper <dietz AT rotfl.franken DOT de> wrote: That is still slower than a LTO4 drive. It would also be a low compression rate. Also I would bet if you had clie
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Fri, 13 Aug 2010 15:06:36 +0200
John Drescher: wrote: Your clients can spool faster? gzip -5 yields around 70 MB/s. The test machine is a mobile [email protected]. In modern terms more the lower end on the performance scale, at least
Author: Paul Mather <paul AT gromit.dlib.vt DOT edu>
Date: Fri, 13 Aug 2010 10:06:58 -0400
Those problems affect software compression, too. 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.
Author: Phil Stracchino <alaric AT metrocast DOT net>
Date: Fri, 13 Aug 2010 10:50:43 -0400
Neither of these issues is applicable to LTO. The compression algorithm (which is a pretty good one) is defined in the LTO specification, and the drive compresses data block-by-block, doing a trial c
Thanks all, this is good information. I'm in the process of finishing a full 6TB backup, will see how hardware compression performed. ________________________________________ From: Phil Stracchino [a
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Fri, 13 Aug 2010 20:23:48 +0200
You: Hmm, I can't reproduce them with gzip on the data in question. Ack. I read the link after posting ;-). LTO should behave fine in that respect. At least LTO should be fine here, too. -- This SF.n
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Fri, 13 Aug 2010 20:35:27 +0200
Phil Stracchino: In theory I agree, at least to the first point (I read the link from that other mail.) In practice, I can remember at least one story about incompatibilities between different vendor
Remember also that if you are trying to minimize tape/disk/other backup media space used, and using encryption, you will need to use software compression. The FD compresses before encrypting; once e
Author: John Drescher <drescherjm AT gmail DOT com>
Date: Fri, 13 Aug 2010 17:10:33 -0400
LTO4 and above have builtin encryption. Does bacula support that yet? John -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Sat, 14 Aug 2010 15:34:49 +0200
Peter Zenge: Ack, that was point #3, which I completely forgot ;-). -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/s
Author: Phil Stracchino <alaric AT metrocast DOT net>
Date: Sat, 14 Aug 2010 11:49:17 -0400
Also, compression before encryption makes encryption harder to crack, as it eliminates redundancy in the data which can potentially simplify the task of attacking the encryption. -- Phil Stracchino,
Author: Paul Mather <paul AT gromit.dlib.vt DOT edu>
Date: Sat, 14 Aug 2010 12:41:50 -0400
Maybe, then, your job is not I/O bound? If backup is limited by the speed at which you can write to tape then it logically follows that you will get the observed behaviour you mention above. More com
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Sat, 14 Aug 2010 19:06:14 +0200
Phil Stracchino: Indeed. -- 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 ____________________________
Author: Dietz Pröpper <dietz AT rotfl.franken DOT de>
Date: Sat, 14 Aug 2010 19:05:26 +0200
You: Sorry, I was a little unclear - with gzip, file size does not get bigger, regardless of the entropy of the data compressed. Of course. That's what I observe with my ancient DLT drive. -- This SF