On Friday 16 January 2004 15:16, Alastair Neil wrote:
>I just ran amtypetype -f /dev/rmt/0bn, a Sun Storedge L9 autochanger
>and recieved the following:
>
>define tapetype unknown-tapetype {
> comment "just produced by tapetype prog (hardware compression
> on)" length 34169 mbytes
> filemark 28 kbytes
> speed 1787 kps
>}
>
>I'm confused because I believed this to be a DLT8000 drive which
> should be closer to 80 MBytes compressed, and certainly the speed
> is not what I expected either. I ran amtypetape -c -f /dev/rmt/0bn
> and amtypetape -c -f /dev/rmt/0cbn and received nearly identical
> output:
>
>amtapetype -c -f /dev/rmt/0cbn
>Writing 256 Mbyte compresseable data: 27 sec
>Writing 256 Mbyte uncompresseable data: 56 sec
>WARNING: Tape drive has hardware compression enabled
>Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
> amtapetype -c -f /dev/rmt/0bn
>Writing 256 Mbyte compresseable data: 25 sec
>Writing 256 Mbyte uncompresseable data: 56 sec
>WARNING: Tape drive has hardware compression enabled
>Estimated time to write 2 * 1024 Mbyte: 448 sec = 0 h 7 min
>
>Host is a Sun E250, with HVDS adaptor.
>
>Does anyone have experience with this drive?
First, thats Gb not Mb reported above when in the vernacular.
34.169Gb. The drives native, uncompressed capacity is nominally 40Gb.
Second, for a good number of reasons, most of us here would like to
see the drives hardware compressor turned off. What you are seeing
above is the result of having it turned on, feeding a drive thats
basicly a 40Gb drive, but since the data from /dev/urandom, which is
used to feed amtapetype, is not at all compressable, and in fact will
expand when run thru the average hardware compressor, by about the
error you see above.
Makeing use of software compression can beat the hardwares efficiency,
sometimes by quite large values. Using a tape set to 3660Mb,
actually a DDS2, I have had amanda tell me that its has put over 12Gb
on one of those tapes occasionally.
The tape has now been written in compressed mode, so even if you turn
the switches off, it will set it back to compressed during the tape
recognition phase after you insert the tape. AFAIK, the only way to
uncompress a tape once compressed is to rewind it, read the label out
to a scratch file usng dd, rewind it, turn the compression off with
the appropriate mt commands, write the scratch label file back to it
with dd, followed, without rewinding, dd'ing enough data from
/dev/zero to force a buffer flush in the drive, thereby re-writing
those hidden bits and turning off the compression. This will of
course destroy all data on that tape, so you may want to script that
up to be done on each tape as it comes round in the sequence, before
the next run of amdump, until they are all done.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
