On Tuesday 13 August 2002 04:32, Conny Gyllendahl wrote:
>Hi all!
>
>I have been trying to set up Amanda to back up our Solaris 8 boxes
> and one of the first steps was to get a tapetype for our tapes.
>
>The taper is reported as "HP DDS-3 4MM DAT" (by `mt status`). I
> don't know any additonal data about this drive since it is in an
> unmarked case (unless I crack it open and look around).
>
>The tapes are "Sony DGD125M", 125 metres with a native capacity of
> 12 GB.
>
>However, after running tapetype I get a tapetype with a capacity
> of around 8.5 GB (86xx-87xx mbytes), also with different values
> for filemarks. Also, the first time I ran it using /dev/rmt/0bn I
> got a type with a large value for filemark (around 1 mmb) and
> when running it twice with /dev/rmt/0n I got either 0 or 32 kb
> (the first one when specifying estimated size to 12 GB and the
> latter without specifying any estimated size).
>
>So, anyone know why I am not getting the expected size?

The drives compression is turned on?  Using hardware compression in 
the drive confuses the heck out of amanda in the first place as she 
then has no idea how much the tape can actually hold.  Amanda 
counts bytes *after* whatever compression is specified in the 
dumptype.

Second, tapetype uses /dev/urandom as the data source.  urandom 
data, because it is so random, isn't compressible by any dumb 2-7 
RLL hardware compressor, and will in fact grow larger by quite a 
bit as it attempts to compress it, hence the low detected capacity.

So turn off the drives compression, amanda can do a far better job 
of compressing things anyway.

Note that this can be difficult to do because the compression flag 
is in a 'you can't see it' tape header and even though the drives 
switches have been turned off, the tape recognition phase the drive 
goes thru when  new tape is inserted will turn it back on if that 
tape has been written to with the compression turned on.

The only reliable method I've found to fix that is to dd the tape 
label to a scratch file, rewind the tape, turn off all compression 
with mt, then feed it (useing dd) sufficient data from /dev/zero 
(10 megs or so, eg more than the drives buffer) in order to force 
it to re-write this hidden header that saves the current settings 
as it flushes the 'about to overflow' buffer to tape.  Once thats 
done, the tape is then rewound again and dd is used to restore the 
tapes label block from that scratch file, using the rewinding 
device this time which will force the buffer flush, thereby 
actually writing the label.

Any data that *was* on the tape is of course lost by doing this, but 
short of reading the whole tape out to a holding area big enough to 
hold it, doing the above, then re-writeing the holding area back to 
the tape, I don't know of a way to prevent this data loss.  In the 
normal course of daily backups, that data will be saved again 
shortly anyway.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.11% setiathome rank, not too shabby for a WV hillbilly