[2067] in linux-scsi channel archive
Re: compression mode for HP1533A streamer
daemon@ATHENA.MIT.EDU (Jeffrey B. Siegal)
Wed Jun 25 02:49:21 1997
Date: Tue, 24 Jun 1997 23:47:06 -0700
To: Pete Popov <pete@jones.asd.sel.sony.com>
From: jbs@quiotix.com (Jeffrey B. Siegal)
Cc: ClimServ <climserv@info13.polytechnique.fr>,
Uwe Schmeling <uschmeli@gibson.csa.de>, linux-scsi@vger.rutgers.edu
At 10:26 6/24/97, Pete Popov wrote:
>Not true. The 2X is the "average" compression ratio of the DCLZ
>algorithm that DDS DAT drives use. This number is the average of
>the compression ratio of text files, binary files, graphic image
>files, etc. It's true that binary files will not compress much,
>but other files, such as text files, will compress a lot, so
>you don't need "highly redundant data" in order to achieve the
>2X compression ratio.
I tested this using a Sun (actually Archiv) DAT drive. I got less than 2X
compression using the built-in compression on fairly typical my backup set.
Sending the drive a stream of zeros, I was only able to achieve about 2.5X
compression.
>> When I have to shrink 2.5 GB of binary, I do not use the internal
>> compression scheme of the HP1533. I use
>> ...|gzip -9|dd of=<my_device> bs=<my_blocksize> conv=sync .
>> It takes a lot of cpu, but it is efficient in terms of compression
>> ratio.
>
>I'm not sure that gzip is so much more efficient, if it's more
>efficient at all, to make it worth increasing the backup time
>by so much.
Using gzip (*not* gzip -9), I was able to cut my backup time (and,
equivalently, tape usage) roughly in half due to gzip's superior
compression. This consumes approximately 60% of the available CPU on a
PPro 180 (but I prefer to do backups on an idle system anyway) to keep the
tape going at full speed. zgip -9 is much slower (the PPro 180 is too slow
to drive the tape at full speed) and doesn't improve compression all that
much.
