On Friday 09 August 2002 17:37, Will Aoki wrote:
>I'm running Amanda 2.4.2p2 (modified from the Debian 2.4.2p2-4
> packages) on Linux with a Seagate STT20000A IDE tape (via the
> scsi-emulation driver) and 10GB native Travan tapes. I'm using
> software compression - hardware compression is (or should be)
> off.
>
>I recently added another host with about 9GB of data to my backup
>routine. Most of the data is mounted from a NetWare box. I've
> split the volumes into 1-2 GB chunks with tar.
>
>
>Some nights, to some tapes, my backups run fine. I get about 8 GB
> dumped to tape:
[...]
>'dd' fits about 10GB of data to the tape, approximately equal to
> its native capacity. If hardware compression were on, I'd expect
> more, so I infer that hardware compression is off. But, when I
> re-amlabel the tape and run dumps to it again, I still only get 5
> GB.
>
>
>I can think of these possibilities:
>
> 1 Amanda is not correctly reporting the amount of data it
> dumped to tape. (But tape time seems to increase with reported
> data taped, making this less likely.)
> 2 Something is switching compression on and off behind my
> back.
I suspect this is the case as once a tape has been written to with
the compression on, its a female dog to get it shut off.
> 3 Hardware compression is on, but is so poor that it
> can't compress a stream of 0x0s, making my test for compression
> fail.
The std test for the hardware compression isn't /dev/zero which a
tape drives hardware 2-7 RLL can smunch quite well IIRC, but from
/dev/urandom which isn't touchable by almost any compression method
with most causing a rather heavy expansion, sometimes as much as
doubling size of the data on the tape.
The util program 'tapetype' can tell you if its on because the tape
will hold much less (40-60%) than the advertised amount of data.
If the compression is truely off, then its rather closer to 90%.
It uses /dev/urandom as the test data source.
Now, if the tape is turning its own compression back on, the only
cure that I've been able to make work is to dd the tape label to a
scratch file, rewind the tape, use mt to shut off all known methods
of compression, and then use dd with if=/dev/zero and of=/dev/tape
count=525,000 ( or more, the idea being to *make* the drive flush
the buffers to tape) at which point any compression flags that
might be set in the tape header you can't see, will be turned off.
Once a few dozen megs have been written, the tape can be rewound and
dd used to restore the label. At this point the compression should
be defaulted to off *for that tape*. Obviously this needs to be
done to all tapes in the rotation.
> 4 On some, but not all, of my supposedly-identical tapes,
> my drive uses 100MB filemarks.
That might be something in the factory formated header for that tape
brand. Generally its ignoreable.
> 5 The tape gnomes are switching out my tapes at night while
> I'm asleep.
I've had them forget to switch tapes quite a few times, does that
count? :-)
Now, since this is a large post, I'm gonna snip, a lot... Above and
below.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.10% setiathome rank, not too shabby for a WV hillbilly
|
