Amanda-Users

Re: Odd amstatus results

2005-04-04 00:26:13
Subject: Re: Odd amstatus results
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Sun, 03 Apr 2005 23:14:30 -0500
On Sunday 03 April 2005 22:41, Nick Jones wrote:
>I have a DDS-3 drive with DDS pass through enabled (should mean
> compression is off), but I keep getting amstatus results that
> produce this:
>
>taped           :   1     46524k     33639k (138.30%) (  0.18%)
>  tape 1        :   1     46524k     33639k (  0.39%) DailySet102
>
If thats a DDS3 drive, those figures look pretty bogus to me.  A DDS3 
should have a native, compression off, capacity of around 12GB.  And, 
even if the drives builtin compression was on, that still doesn't 
compute as it assumes a compressor good for >4x, and hardware 
compressors aren't *that* good that I know of, 2.6 at best.

On thing that should be more widely known is that these drives all 
keep a compression status flag in the tape recognition header, and 
regardless of your wishes, if when the drive does its tape 
recognition phase stuff when a tape is inserted, it finds that flag 
set, the compressor will be turned on regardless of any dipswitch or 
software settings you think are in effect.

The only way I've found to actually turn it off once its been enabled 
is to rewind the tape, turn it off, and then force feed write enough 
data to make the drive flush its buffer, at which point the 
compression status will be tallied as it exists when the write is 
forced.

Typically thats done by a sequence like this, using the non-rewinding 
device:
----
rewind the tape with mt

read the first 'label' block out to a scratch file using dd

rewind the tape with mt

set the compression off using both variations of this using the mt 
command

rewrite the label block using dd

dd enough data from /dev/zero to force the buffer flush, usually 
around 1.5x the rated size of its buffer.

rewind the tape
----
Now, you should be able to eject it, and reinsert it without turning 
the flag back on.

Now, to verify its off, (remember to save that label block file for 
this)

run an amtapetype session using the -e 12GB (see the manpage for exact 
options) as one of the options.

This should give you a true raw tape figure after a while, possibly 
several hours, and it should also tell you in that output if the 
compression is on.

Now, because the run of amtapetype will destroy the label, rewind that 
tape one more time and dd that label block back to it again using the 
rewinding device this time, thereby restoreing amanda's ability to 
use the tape when it comes around in the schedule.

>I do have a few clients that do client side compression with tar. 
> Is this just a case where the client compression makes the backup
> bigger or am I some how doing double compression?  (In this case
> it's a linux machine's root partition).

Which shouldn't be exactly a dir full of .bz2's, it should be very 
compressable, as in to < 40% of its original size in my experience.

>Thanks in advance for any suggestions.
>
>
>--
>Nick

-- 
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.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

<Prev in Thread] Current Thread [Next in Thread>