John Drescher schrieb: > > I'm testing our new changer which is equipped with 2 LTO-4 drives. > > What should I expect from LTO's hw compression? > On LTO2 and DLT I have seen between 1.1:1 to 2.5:1 but mostly between > 1.4:1 and 2:1.
Ok. > > I've seen LTO-3 tapes with > > 800+ GB data. Here are the volbytes number I got with LTO-4 so far. > > > > volbytes: > > 1,164,080,268,288 > > 1,138,440,038,400 > > 1,180,908,417,024 > > > > This is a compression ratio of 1,45:1. > > > > I know that these numbers are highly dependent on the kind of data > > that is backed up. > > > > The data I'm currently backing up is mainly made up of large hdf > > files. > > > > # du -sh * > > 1,4G 16bit_chan0.hdf > > 0 16bit_chan0.hdf_pdetTrigger.log > > 325M 8bit_chan0.hdf > > 201M 8bit_chan1.hdf > > > > # bzip2 * > > > > # du -sh * > > 447M 16bit_chan0.hdf.bz2 > > 4,0K 16bit_chan0.hdf_pdetTrigger.log.bz2 > > 219M 8bit_chan0.hdf.bz2 > > 652K 8bit_chan1.hdf.bz2 > > > > > > So bzip2 seems to be able to compress the data far better (3,4:1), but > > the drive has to do it in "real time", thus is might be slower, > > although compression is implemented in hardware. > > > It has to do this at 120 MB/s for LTO4 drives which is a lot faster > than any software compression I have seen. > > I would consider the compression closer to gzip fast (or LZO) than > bzip2 and also there is one big difference the hardware compression in > the tape drive compresses block size chunks at a time instead of the > whole file. # gzip -1 * # du -sh * 644M 16bit_chan0.hdf.gz 4,0K 16bit_chan0.hdf_pdetTrigger.log.gz 252M 8bit_chan0.hdf.gz 3,2M 8bit_chan1.hdf.gz That's about 2,1:1 on a Xeon CPU server that is not comparable with a LTO-4 drive. > > I'm just wondering if I have to set a special density code with mt > > (which I don't know at the moment)? > Doubtful. I have never seen a tape drive with variable compression methods. I guess the compression ratio is fine, even though I thought the data would be highly compressible. Ralf ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
