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