On Thursday 26 December 2002 12:16, Axel Haenssen wrote:
>Hi Guys,
>can somebody enlighten me a little about the ./tapetype command?
>What determines the "blocksize" and what's meant by "estsize"??
>Thanks a lot and happy new year.
>Axel

I think its supposed to be able to figure that out on its own.  Or 
it could try and force the issue to bs= 32k or or 64k.

Be aware that when running, it uses /dev/urandom as the data source, 
and this data is not normally compressible by the tape drives 
hardware compressor, and may even grow by 5% (or more) in passing 
thru such a compressor.  This will cause tapetype to give falsely 
low estimates of the actual capacity of the drive.

For amanda's use, its generally prefered to have the hardware 
compressor turned off, and have any compression done by amanda as 
it runs things provided you have the cpu horsepower to do so.

The advantage then is that amanda counts bytes sent to the drive 
after compression and can therefore know how much the drive can 
hold pretty accurately.  Actual variations then are in the tape 
lengths packed in the individual cartridge, which can also vary.  I 
just reduced my entry for a DDS2 tape by 10 megs because it hit the 
end of the tape during a backup 2 weeks ago, and I suspect the 
reason was that this particular tape might have been a foot shorter 
than the average.

If you give it an estimated size for a start seed, it will write 
that amount non-stop and faster than it would by stopping and 
checking for an EOT signal from the drive.  Set that estimate a bit 
smaller so that it can do that much, then revert to the write and 
check mode and it till find the end of the tape a bit faster.  For 
a DDS2 tape which is supposedly 4gigs without compresion, try 
3.7gigs for an estimated size.  Typically it will find something in 
the 3.850 gigs range for such a tape.

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