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
|
