I have a file system which is about 35GB. The problem I have is that
although I use "/dev/rmt/0cn" as the dump device, the tape bails at
around 20GB. Shouldn't I get at least 40Gb compressed? My tape
cartridge is 20GB Native/40GB compressed, and on the documentation I
could find, the only mention on compressing backups points at using
"c" for compressed on DDS-4 drives. Anyone has a clue out there?
Is there something I'm not doing for getting this hardware compress
going? Or would I be better off doing software compress? If so, which
is the best recommended method for software compress? I'm running
Solaris 8 02/02 on an E4500 server.

Pedro Cortez <nomada7@hotmail.com> wrote:
> I have a file system which is about 35GB. The problem I have is that
> although I use "/dev/rmt/0cn" as the dump device, the tape bails at
> around 20GB. Shouldn't I get at least 40Gb compressed?

Depends on the drive/cartridge and it depends on the data.  Already
compressed data (.jpg, .mpg, .mp3, .zip) doesn't compress any further.

Do you have a spare tape?

If you do 'dd if=/dev/zero of=/dev/rmt/0cn bs=256k'  How many blocks get
onto the tape before it fills?  Since /dev/zero is highly compressible
you should get a lot more than 
20 GB / 256k =~ 78000 blocks

If you get double or more than that, your drive is compressing.  If you
get around 78000, it's not.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Pedro Cortez (nomada7@hotmail.com) wrote:
: I have a file system which is about 35GB. The problem I have is that
: although I use "/dev/rmt/0cn" as the dump device, the tape bails at
: around 20GB. Shouldn't I get at least 40Gb compressed? My tape
: cartridge is 20GB Native/40GB compressed, and on the documentation I
: could find, the only mention on compressing backups points at using
: "c" for compressed on DDS-4 drives. Anyone has a clue out there?
: Is there something I'm not doing for getting this hardware compress
: going? Or would I be better off doing software compress? If so, which
: is the best recommended method for software compress? I'm running
: Solaris 8 02/02 on an E4500 server.

I think you are missing the point that you only have a 20GB backup device,
which COULD hold 40GB if the data can be compressed 2:1.

If the data is non-compressable, meaning .zip, .gz, .gif, .jpg, there isn't
going to be any additional compression, software or hardware.

Also keep in mind whatever data is non-compressable, that has to be
subtracted from the raw storage. So if you have 35GB of data and 10GB is
non-compressable, you only have 10GB left that could compress but thats only
20GB if 2:1. So the tape will only hold 30GB of data total, or 5GB short.

You really have to start looking at the tape as a 20GB storage, with "a
little bit" more possible.

-bruce
bje@ripco.com

In article <c6r6qc$b5t$1@e250.ripco.com>,
	bje@ripco.com (Bruce Esquibel) writes:
> Pedro Cortez (nomada7@hotmail.com) wrote:
>: I have a file system which is about 35GB. The problem I have is that
>: although I use "/dev/rmt/0cn" as the dump device, the tape bails at
>: around 20GB. Shouldn't I get at least 40Gb compressed? My tape
>: cartridge is 20GB Native/40GB compressed, and on the documentation I
>: could find, the only mention on compressing backups points at using
>: "c" for compressed on DDS-4 drives. Anyone has a clue out there?
>: Is there something I'm not doing for getting this hardware compress
>: going? Or would I be better off doing software compress? If so, which
>: is the best recommended method for software compress? I'm running
>: Solaris 8 02/02 on an E4500 server.
> 
> I think you are missing the point that you only have a 20GB backup device,
> which COULD hold 40GB if the data can be compressed 2:1.

The best I've ever got out of the compressing DDS drives is 1.6:1
in real world use, and that is on C source code.

-- 
Andrew Gabriel

Andrew Gabriel <andrew@cucumber.demon.co.uk> wrote:
>> I think you are missing the point that you only have a 20GB backup device,
>> which COULD hold 40GB if the data can be compressed 2:1.

> The best I've ever got out of the compressing DDS drives is 1.6:1
> in real world use, and that is on C source code.

Most tape drives seem to have similar algorithms.  I get a variety of
compression across tapes.  Exchange 5.5 always seemed to be the most
consistent, and was usually within 5% of (56/35) or 1.6:1.  Other
systems were much more variable.  I would often generate Unix
incremental DLT7K tapes that held more than 100G for (100/35) or 2.8:1.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

I'm only backing up the /export directory in my servers, which does
not have any .mpg, .jpg of any sort. There are only O/S images, and
patches (not compressed), and so that is why I'm so bombed that the
drive would not compress at all! I guess if someone could help me up
compressing (software compress via tar, zip or so) the /export
directory I would really appreciate it. Has anyone confirmed that I'm
using the right device for compressing (/dev/rm/0cn)?? thanks.

bje@ripco.com (Bruce Esquibel) wrote in message news:<c6r6qc$b5t$1@e250.ripco.com>...
> Pedro Cortez (nomada7@hotmail.com) wrote:
> : I have a file system which is about 35GB. The problem I have is that
> : although I use "/dev/rmt/0cn" as the dump device, the tape bails at
> : around 20GB. Shouldn't I get at least 40Gb compressed? My tape
> : cartridge is 20GB Native/40GB compressed, and on the documentation I
> : could find, the only mention on compressing backups points at using
> : "c" for compressed on DDS-4 drives. Anyone has a clue out there?
> : Is there something I'm not doing for getting this hardware compress
> : going? Or would I be better off doing software compress? If so, which
> : is the best recommended method for software compress? I'm running
> : Solaris 8 02/02 on an E4500 server.
> 
> I think you are missing the point that you only have a 20GB backup device,
> which COULD hold 40GB if the data can be compressed 2:1.
> 
> If the data is non-compressable, meaning .zip, .gz, .gif, .jpg, there isn't
> going to be any additional compression, software or hardware.
> 
> Also keep in mind whatever data is non-compressable, that has to be
> subtracted from the raw storage. So if you have 35GB of data and 10GB is
> non-compressable, you only have 10GB left that could compress but thats only
> 20GB if 2:1. So the tape will only hold 30GB of data total, or 5GB short.
> 
> You really have to start looking at the tape as a 20GB storage, with "a
> little bit" more possible.
> 
> -bruce
> bje@ripco.com

Pedro Cortez wrote:
> I'm only backing up the /export directory in my servers, which does
> not have any .mpg, .jpg of any sort. There are only O/S images, and
> patches (not compressed), and so that is why I'm so bombed that the
> drive would not compress at all! I guess if someone could help me up
> compressing (software compress via tar, zip or so) the /export
> directory I would really appreciate it. Has anyone confirmed that I'm
> using the right device for compressing (/dev/rm/0cn)?? thanks.
> 
Should be obvious, but have you checked the internal DIP switches on the
DDS-4 drive? They might be set to disable compression. Also, post your
/kernel/drv/st.conf file, as there might be some problem in there with
the drive you're using.

-- 
Bill Wyatt (REMOVEwyattTHIS@cfa.harvard.edu) "remove this" for email
    Smithsonian Astrophysical Observatory  (Cambridge, MA, USA)