On Monday 20 January 2003 02:54, Martin Oehler wrote: >Hi! > >I'm searching for the tapetype of the following LTO-drive: > HP Ultrium 1-SCSI > >It has a capacity of 100/200 GB. I couldn't find an entry >in the FAQ-O-Matic about this. > >Thanks in advance, >Martin Öhler
In the most recent snapshots is a new program, 'amtapetype' which replaces the older version. I have not run it yet, so I don't know the syntax, but the old tapetype program that you had to build seperately had cmdline options to give it an estimate of the tapesize which would then allow it to do its thing somewhat faster. I'd assume something similar for this one, check any notes in the archive for diffs. It will, when run, find the size of the drive (it will take quite some time because it will write to EOT twice to do it) and will output that data you need to define this tapetype to the screen or to a new file you can merge into amanda.conf after giving the config a descriptive name. In any event, running it should be done with the drives compression turned off for a couple of reasons, 1st being that the gzip that amanda can use is at times considerably more efficient at compressing things, and 2nd, if compression is on when amtapetype is run, you will get erroniously low answers because it uses /dev/urandom as the data source for these tests, and /dev/urandom isn't compressible, and in fact will grow, often by more than15% when run thru a hardware compression chip. Generally speaking, if the machine has the horsepower to do the compression its a very good idea to turn the drives compressor off and leave it off. Amanda can often put more in real world bytes on the tape using its compression than the hardware can by wide margins. A few of the directory's I compress by my choice of dumptype in the disklist, will compress to less than 10% of their original size. Many more will be less than 20%. Overall, I get about 40% here with some dirs not being compressed at all as they contain already compressed stuff. If running in a client-server setup (which I am not) then its often the case where the client may well have more cpu than the server, in which case do the compression on the client. This has the added advantage of reducing the network bandwidth required to move the compressed file to the server, and several clients can be doing their thing at the same time, which also will help to speed things up. My $0.02 worth. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly