On Monday 11 August 2003 12:21, Craig White wrote:
>Sorry about the messy copy/paste and no threading - for some reason,
> I am on the digest of this list - which I don't like and I haven't
> found a way to switch from digest to regular emails...so I read the
> replies from Gene/Jon and have follow up...
>
>Gene>
>
>> From the above figures its apparent that A: you're not using the
>> latest amtapetype, and B: hardware compression is on.
>>
>> Useing hardware compression does this list of things:
>>
>> Now, if I've convinced you to turn the hardware smuncher off,
>> be aware that a DDS tape, once written to with the compressor
>> on, is a bit of a problem child to get it to turn off because
>> even though you have reset the dipswitch to off mode, the
>> tape recognition cycle when you put the tape into the drive,
>> will find that flag on the tape and turn it back on for you.
>> Very thoughtfull of the drive, NOT!
>>
>> What this means is that to get rid of that flag on such a
>> tape, one must do something like this:
>>
>> mt -f /dev/nst0 rewind
>> # now, save the tapes label
>> dd if=/dev/st0 of=scratch bs=32k
>> # turn off the compression
>> mt -f /dev/st0 defcompression off (or -1 for some mt's)
>> mt -f /dev/st0 compression off
>> # now put the label back using non-rewinding device
>> dd if=scratch of=/dev/nst0 bs=32k
>> # and flush the drives buffers to force the flag update
>> dd if=/dev/zero of=/dev/st0 bs=32k count=130 (or more)
>> # now read the label out to stdout to show you its still ok
>> # but please note that all the other data on the tape will be gone
>> dd if=/dev/st0
>>
>> Re-run amtapetype after doing the sequence above to your
>> test tape. See the man page and give it the correct
>> estimated size as an argument. That will speed it up some.
>> Then do it to all tapes that are to be reused as you
>> cycle them thru the drive until you've treated all your
>> tapes to the no-compression as shown above. Or you could
>> make a script out of it and do it before fireing off amanda.
>> But be aware that the above requires root access, whereas
>> amanda will get her own, so its an "su amanda -c 'amdump
>> /configname/'" in your root script.
>
>----
>OK - understood - I am not one to piss into the wind...hardware
>compression off is the plan - Macintosh/Windows roots - hardware
>compression was easy, Linux/Amanda requires much more low level
>configuration than I had planned to ever learn but there is gain so
> I endure and bow to your great pearls of wisdom. Before I go any
> further, THANK YOU Gene & Jon for your terrific replies
>
>Anyway, I presume that I don't need the tapes, can wipe out curinfo
> & tapelist for this config and start from scratch, erase the tapes
> and not worry about dd'ing the headers off and back onto the tapes.
>
>Thus my specific questions...
>
>1 - if I issue the command to turn off hardware compression...
># mt /dev/nst0 compression off (or -1)
>or is it
># mt /dev/st0 compression off (or -1)
either one as long as its a valid syntax for your version of mt, it
seems ther is more than one version being packed in the distributions
today.
You'll also need the line for 'defcompression' with whatever syntax is
applicable to your 'mt'.
>Must I do that each time I restart (as in add to rc.local?)
>Must I do that before I run any amdump?
>How often do I have to turn compression off?
Since amdump rewinds and and rereads all those headers, the sample
script I sent along must be run, including the long write using dd
from /dev/zero, and done without rewinding the tape until the
/dev/zero write has been completed. Otherwise the flippin drive just
resets the flag to whatever it is on the tape when the tape is
inserted. Its PITA, is what it is. If you don't have a changer,
then its easy, just put it in front of an "su amanda -c 'amdump
/your_configs_name/'". But you'd better have the right tape in the
drive because it will be destroyed except for the label.
You can run it in rc.local, or in a wrapper script around amdump, but
it must be done *before* amdump puts her pizza hooks onto the tape.
And you must run that routine aganst every tape until they've all
heard the message.
>
>2 - isn't the chg-manual script supposed to send an email to the
> mailto addresses in the amanda.conf when it needs another tape?
>
Yes AFAIK is should, to the Mailto: in your config.
>3 - is there any 'user' interface for Amanda such as a webmin module
><http://www.webmin.com> or must I script out common operations for
>users?
There have been offers, but as its of little use once amanda is up and
running, no one has followed thru. Once its running, the most often
edited file will be the disklist as your network expands or
contracts. Thats a no-brainer once you get the hang of it.
Besides, you are the "user/sysadmin", and if one of your client
machines gets a tummy ache & needs a recovery, its probably going to
be up to the sysadmin to do it anyway.
We've had some discussions, and the general consensus is that the
"client/users" should have no access, having your salesdrone Joe
Six-Pack wandering around in the archives could cheerfully read the
companies payroll if he had perms, so trying to setup rights on a per
user basis, simply is impracticle in practice and isn't even
supported on a per file on the tape basis anyway. Let the sysadmin
(you) handle the recoveries so you can control what goes back on
whose machine. root must do any recoveries done...
>
>lastly, in reference to Jon's reply...
>
>>> Do I adjust the numbers of the 'length?'
>>> Does the length of 9675 seem small for a DDS-3 (125 meter
>>> / supposedly
>>> 12/24 Gigabyte or does formatting / filemarks / labels
>>> /etc cut 20%?
>>
>> Adjusting the value of a meaningless number is an exercise
>> in futility.
>
>Exercises in futility is something that I seem to do well. Sorry but
>some of the documentation is spread out and I didn't find it
>all/comprehend it all but I'm getting it slowly.
>
>Thanks,
>
>Craig
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% 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.
|
