Amanda-Users

Re: controlling hardware compression?

2003-05-24 02:33:06
Subject: Re: controlling hardware compression?
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: Jon LaBadie <jon AT jgcomp DOT com>, amanda-users AT amanda DOT org
Date: Sat, 24 May 2003 02:31:33 -0400
On Saturday 24 May 2003 01:44, Jon LaBadie wrote:
>On Sat, May 24, 2003 at 12:17:30AM -0400, Gene Heskett wrote:
>> On Friday 23 May 2003 23:47, Mathias Körber wrote:
>> >Paul Bijnens <paul.bijnens@x...> wrote:
>> >> IMPORTANT!
>> >> You also have to know that, no matter what you had executed
>> >> as setting for the compression of your drive, if you READ a
>> >> tape, the drive will set itself to what the mode of the tape
>> >> was. If you insert a tape written with hardware compression,
>> >> disable the drive hw compr by "mt compression off" (verify
>> >> with "mt status"), then read the tape, it's back in hardware
>> >> compression! (verify again with "mt status"). This implies
>> >> that if you want to overwrite a tape with the other mode, you
>> >> may NOT read anything on the tape after setting the mode.
>> >
>> >This is the part that worries me. Amanda does perform a
>> > tape-read at the beginning of amdump etc.
>> >While that usually is no problem with amdump (as only labeled
>> > tapes should be used anyway and hopefully they are of the
>> > correct type assuming that tapes have been labeled withthe
>> > correct compression setup), amlabel itself also performs a
>> > read and may switch back to uncompressed if one tries
>> > re-labeling a previously uncompressed tape to compressed or
>> > vice-versa.
>>
>> Thats exactly what will happen in almost all instances from my
>> experience.
>>
>> >I would think a -c option to amlabel which makes it set the
>> > compression just before writing the label would be useful. If
>> > could name a program (shell script) which does the actual
>> > setting (such as mt or stinit). Other tools in the amanda
>> > suits might benefit from this too.
>>
>> Change that to a -c true/false, and it would be a winner.  The
>> problem with that is that the various drives take various
>> commands to effect that, so it might be required to have a
>> preset file, built by the user, that contains the required
>> command syntax to do that to *his* drive.  It would also require
>> a bit of must read documentation, and with some users, thats
>> always going to be a problem due to a general lack of RTFM.  In
>> particular the noobie is going to be asking a lot of why can't
>> amlabel just work, when in fact it cannot find the syntax file
>> the user hasn't generated.
>
>Kinda tough to do on a system such as mine which doesn't have
>commands or calls to change compression settings.  It is done
>on the "open" call to the tape drive (and driver) by selecting
>a device name.  Like you call nst0 or st0 to select no/rewind.
>How do you change that behavior after opening the drive?
>
>Of course that is also the reason I don't suffer from the change
>upon read problem you have.

I'd imagine on the solaris system it turns off the compression 
everytime it opens the path to the drive if you select the 
noncompressing device?  So basicly you would never need the -c 
switch, which if the function is added correctly, would be a simple 
matter of your not making use of the -c option.

Am I understanding how solaris does it correctly?

I've not been able to grasp the methods to control the stinit 
function we have, and it may be possible to do it there, but again 
thats pretty system/drive specific.  I expect I'm always doing a 
man stinit way too late at night :(

>> >> amtapetype from 2.4.4 does a write without a read (and will
>> >> detect hw compression if still on :-) ).
>>
>> What does this portion of its report look like?
>
>An error message and exit.  No report.

And the error message is that hardware compression is on, please 
turn it off?  That makes sense if so.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.