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
