Gene,

Thanks - I was wondering about that.  I'm using /dev/nst0 - do I need use a different device to avoid compression?  I'm really new to this - thanks for the help.  I'm posting a follow up with some SCSI issues I had in setup this morning...

-John

 Gene Heskett <gene_heskett AT iolinc DOT net> wrote:

On Tuesday 04 February 2003 07:37, John Cunningham wrote:
>Hey guys - just wanted to post this. It's a tapetype for IBM
> DDS-4 Autoloader running 150M 20/40 GB DAT tape...
>
>define tapetype XLIX {
> comment "IBM DDS-4 120 / 240 GB Autoloader"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2282 kps
>}

John, that's supposed to be a 20 gig tape, so it looks as if the
hardware compression was on when you ran tapetype. That will give
you somewhat low estimates for the size as tapetype uses
/dev/urandom as the data source, and the output of /dev/urandom
will generally overpower the hardware compressors and cause the
data to actually be expanded a bit. So the drive actualy wrote
more data than tapetype fed it, leading to an early EOT finding in
terms of the amount of data sent.

If thats the case,! this is a dds tape, and you will probably need to
go back up the list here and see how to remove compression from
*that* tape from one of my previous posts on the subject.

In any event, gzip can beat the hardware compressors 90% of the
time, so generally speaking, if the server has the horsepower to do
the compression, you should let it do so for those disklist entries
that will compress. About 1/3rd of my disklist won't compress, its
archives and such that already are, but the rest do really well, so
the average output size here is about 40% of the input size.

--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.23% setiathome rank, not too shabby for a WV hillbilly