On Saturday 21 September 2002 08:38, Neil wrote:
>Gene Heskett writes:
>> Looks good, but it appears from the kb/s rate you are getting,
>> that the drives hardware compression is turned on, which doubles
>> the effective data rate. Thats a maximum of a 400kb/s drive
>> without that.
>
>Are you saying that setting hardware compression to off is better?
>
There are many reasons to shut it off, yes. Software compression
can do twice as good or more. The tradeoff is time because gzip at
its best compression rate does warm up the cpu unless you are
already running setiathome which will keep it at 100% anyway.
Thats my case here as you can see by the .sig and ranking. <G>
>> However, this also means that the true tape capacity is hidden
>> from amanda because amanda has no idea of the compression ratio
>> the hardware achieves. This is why there is a tapetype
>> definition in your amanda.conf.
>>
>> Turn the drives compression off, and switch the dumptype chosen
>> in the disklist to something which uses "compress server best",
>> which should put gzip to work on those partitions that contain
>
>How will I be able to do that? From what I have in my
>http://restricted.dyndns.org/amanda.conf, amanda is using dump
> utility. Am I correct? And I heard that dump is the best tool to
> backup our file system. When does gzip comes into play?
The dumper chosen is independant of the compression used. OTOH, I'm
partial to tar, and maybe you should be too because tar allows
exclusions and you'll want to exclude the ./dumps directory as it
can become recursive. Otherwise you''l have to use a seperate
partition for /dumps and leave it out of the disklist. That of
course fixes the size of /dumps, whereas mine floats according to
whats otherwise free in /usr since its a subdir in a 36 gig /usr
partition here. Currently about 16 gigs free, with a reserve
setting in amanda.conf of 40%, meaning it will not switch to
incrementals if I forget to change the tapes for one night.
>> compressable data. It will take time during the run to do this,
>> but the compression ratio can be in excess of 5/1 instead of the
>> drives average of 2/1.
>>
>>
>> Your generated tapetype also indicates the compression in the
>> drive was on as its not quite up to the real capacity of a DDS2
>> tape.
>
>Ok, after dd finishes, I will run tapetype again.
>
>> Obviously it worked, but the final "." in the path isn't
>> required.
>>
>>>I only have 1 tape HP DDS-2. Then I wanted to do a full backup
>>> of my whole freebsd system everyday at 11pm.
>>>
>>>Since it's just 1 tape, is it alright if I configured my device
>>> in amanda.conf as /dev/nrsa0 (non-rewinding)?
>>
>> Thats the correct way for amanda, she will do her own rewinding.
>>
>>>Please comment on my amanda.conf.
>>
>> Turning the drives compressor off is bit tricky since the tape
>> has now been written to in the compressed state. What you must
>> do now is to not only turn the dipswitch on the drive to off,
>> but you must cause the updated status to be written to the tapes
>> internal header, one you can't read or write to directly so you
>> have to beat the drive about the brow a bit to get this updated.
>>
>> Do something along these lines:
>> 1) dd if=/dev/sra0 of=scratch count=1
>
>I tried this but scratch file was not populated.
It should have been 512 bytes. Or gave you an error output that
said what went kaflooey. I assumed that the tape was fully
rewound, but neglected to mention that little detail. Sorry.
In that case, a rerun would have gotten it, but for you its not a
big deal.
>> which will save the tape id data for amanda. By using the
>> rewinding device, we don't have to.
>>
>> 2) mt -f /dev/sra0 compression off
>
>Mine worked as mt -f /dev/rsa0 comp off
>
>> 3) mt -f /dev/sra0 datcompression off
>
>I "man mt" but didn't find similar option as above.
>
-----------------------
defcompression
(SCSI tapes) Set the default compression state.
The value -1 disables the default
compression. The compression state set by compression
overrides the default until a
new tape is inserted. Allowed only for the superuser.
-------------
note, I was wrong, its defcompression, not datcompression. And
"off" is equal to a -1, at least on this linux. Memory, the second
thing to go you know...
My drive has a tally led on the face of the magazine drawer that
tells me if compression is being used, hopefully yours does too.
>> which will turn the compression flags back off that were turned
>> on when the tape was recognized by the drive.
>>
>> 4) dd if=/dev/zero of=/dev/sra0 count=1600000
>
>it's running right now :)
I gave it a pretty good sized count there, and you can ctrl-c out of
it at this point, the object we wanted has been accomplished if the
drive is actually moving tape.
>> Which will fill the drives buffer and force the drive to write
>> to the tape with those compression flags turned back off. If
>> enough data isn't written to the drive to cause this, those
>> flags will remain on forever *for that tape* even if the
>> dipswitch is off.
>>
>> 5) rerun the tapetype and get the true capacity of the tape so
>> you can update that entry in your amanda.conf. It should go up
>> a bit because tapetype uses /dev/urandom as the data source for
>> its test writes, and the data from /dev/urandom is so random
>> that it overpowers the hardware compression and actually grows
>> to be larger on the tape than what tapetype seems to think it
>> is.
>>
>> 6) dd if=scratch of=/dev/sra0 count=1
>
>Since my scratch file wasn't populated, I will have to run amlabel
> after dd finishes.
After tapetype is done instead of dd.
>> which will restore the amanda label to the tape. The rest of
>> the data on the tape will be gone however until you run another
>> pass of amdump. Note that I used the rewinding tape device for
>> all of the above. Otherwise we would have needed to do it
>> manually with yet more mt commands.
>>
>> I have my own disklist entry for /usr broken up into an entry
>> for each subdir in /usr because I have a few subdirs there that
>> contain data thats already been compressed, much of it with
>> bzip2, so I use a dumptype for each directory that fits the data
>> in that directory. Initially set them all to use compression,
>> and look at the email report, any subdir thats reports a
>> compression ratio over 100% needs to be taped as is without
>> further attempts at compression.
>
>Thank you very much Gene and to other folks here.
>This is an awesome support.
>
>This is what I like very much in the Open Source community. :)
>
>Neil
So do I. Which is why I'm sitting iin front of a screen now instead
of figureing out how to get a 1000 lb Azalea bush from the front
yard to the back yard, with a maximum width of access thru the
fences of about 36", about the size of the rootball on ths puppy
after a liberal application of the spade once it was out of the
hole, which was a 2 day project by itself for this old country boy.
It currently has a lifting tripod made out of 16' 2x6's standing
over it but I can't get enough straight lift to slide it into the
pickup bed. No way in h--- that I could handle that puppy in a
wheelborrow even if I was 50 years younger! So I called a friend
with a bobcat sized backhoe last night. And I'm all stove up
today, but I'll get over that.
I think I can get it there by unbolting a section of the neighbors
chain link fence adjacent to the hole its going into, but first I
have to re-rig the straps from the top of the tripod to get a
couple feet more lift. I ran out of fuel, ladder and daylight last
nite.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.15% setiathome rank, not too shabby for a WV hillbilly
|
