On Tuesday 26 March 2002 05:53 pm, Fernan Aguero wrote:
>I'm trying to understand why amanda is only writing
> approximately 19-20 GB on my DDS-4 tapes (HP C5718A, min 20GB
> and up to 40GB with compression).
>
>Supposedly, my DAT40i drive is set from factory with hardware
>compression ON, and host control ON.
>
>According to the documentation that came with the driver, the
>compression is managed through the use of different devices. In
> the same spirit that we have /dev/sa (rewinding) and /dev/nrsa
> (non-rewinding) devices, there is a naming scheme for
> compression and no-compression devices.
>However I don't know which is my device naming convention
> (FreeBSD here).
>
>According to sa(4), on the BUGS section of the man page, I can
> read: "Fine grained density and compression mode support that
> is bound to specific device names needs to be added."
>
>So apparently we're left without it ...
>
>Now how am I supposed to control hw compression? Only through
> the jumpers in the drive? Once and for all?
>I know I can configure amanda to do software compression, this
> is pretty well explained through examples and there are lots of
> dumptypes already there. And I also read that doing both is not
> recommended.
>
>Problem is: I'd like to use hardware compression and leave my
> machines as light as possible on cpu usage. But how do I know
> if hardware compression is taking place?
If a run of tapetype shows less than the drives rated capacity by
more than a 15% error, then compression is obviously on.
Tapetype uses /dev/urandom as the data source for its testing,
and random data is a surefire method to overpower the hardware
compression causeing the data to grow, sometimes by nearly 200%.
Generally speaking, the hardware compression should be disabled.
Then you control the use of compression via the choice of backup
types in amanda.conf, such as 'server fast' or 'server best' or
'client best' etc. Client type choices will offload the
compression duties to the client machine in multimachine nets,
and its often the case that the client is the faster machine and
better able to handle the cpu load of running gzip (or whatever)
on the data before its poured into the network. Doing the
backups after hours tends to make the cpu usage argument a bit
less important.
> i) if the factory default is to have 'host control' ON and I
> cannot do any control from the host over hw compression, should
> I turn 'host control' to OFF?
> If i do this, then upon checking the status of the drive I get
> a column that says 'Compression: unsupported' instead of
> 'Compression DCLZ'
I'd assume thats what it would tell you if the compression was
disabled.
This gets into another sticky wicket in that most of these drives
will switch the comperssion back on if they find a tape during
the header reads thats been compressed previously. I have one
Seagate changer that once a tape has been written to in
compression on mode, cannot ever reconvert that tape to a
non-compressed format. I mention this because its possible that
to turn off the compression and make it stay off, you may have to
start with fresh, never been touched tapes.
>
> ii) perhaps the compression is taking place but my tapetype
> definition is wrong? The following definition was taken from
> the FAQ-O-Matic, although it didn't mention the type of
> cartridge used:
>
>define tapetype HP-SURESTORE-DAT40 {
>comment "just produced by tapetype program"
> length 19560 mbytes
> filemark 1147 kbytes
> speed 2957 kps
> lbl-templ "/usr/local/etc/amanda/normal/HP-DAT.ps"
>}
>
> Maybe I should run tapetype myself with my hw compression
> settings and see if I can get over 20GB of data into the tape?
>
A highly recommended test in this case.
> Or perhaps some of you are using the same drive with the same
> cartridges and can share your tapetype def with me?
>
> What happens if I lie to amanda and set the length to
> 40000mbytes? If it reaches the end of the tape, it will
> reprogram the failed filesystems for the next tape, right?
Not that I've heard about in that sense. If you are asking will
amanda restart that disklist entry on a fresh tape if it runs out
of tape on the current tape, then the answer is yes, that
complete disklist entrys backup will then be written to the next
tape and the previous tapes last file will be incomplete.
>
>Perhaps this is why now amanda is skipping some large
> filesystems ... Could it be that amanda is not even attempting
> to write to tape because of what the tapetype entry says about
> the length?
While thats possible, I'd be called Thomas (the doubter)
>(my largest partition is about 13GB with about 25-40% of it
> being already gzipped files)
Any partition thats that much gzipped already, should have the
compression turned off, doing a straight tar of it. Its quicker,
and your data won't grow to overflow the tape.
>yes, a newbie :)
We all were at some point, and I still ask questions so join the
crowd. We try to be helpfull here. :)
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
98.7+% setiathome rank, not too shabby for a hillbilly
