Amanda-Users

Re: controlling hardware compression?

2003-05-23 12:51:05
Subject: Re: controlling hardware compression?
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: Mathias Körber <mathias AT koerber DOT org>, amanda-users AT amanda DOT org
Date: Fri, 23 May 2003 12:48:34 -0400
On Friday 23 May 2003 10:26, Mathias Körber wrote:
>Hi all,
>[I asked this on UseNet (comp.os.linux.hardware etc), but hope
> someone here may have some insights too..]
>
>
>I just got a Dell PowerVault 100T DDS4 tapedrive and would like to
> ensure that when bcking up with AMANDA (www.amanda.org) the
> hardware compression is OFF.
>
>Obviously I can turn it off on the drive itself (DIP-switch 1) but
> that should also be doable using a SCSI command (thus leaving h/w
> comp available for non-amanda usage if required)

The 'mt' program can control that also.  Unforch, with these tapes, 
the drive, when loading the tape, inpects the flags in the tape 
header thats reserved for the drives use, and happily overrides 
your carefully crafted script.

>Question is: How do I do that? Is there a special tape device
> (/dev/nrmtu0 or such for *u*ncompressed access and the driver
> will take card of that), or does AMANDA know how to send SCSI
> commands to its device [ I could not find anything though on
> first look].
>
>I am running a 2.4.18 kernel.

Not under linux unforch.  In order to change the status of a tape 
thats been written to once, from compressed to uncompressed, one 
must cobble up a script to run against each tape its desired to 
change.

example:
------------------
#!/bin/sh
mt -f /dev/nst0 rewind
dd if=/dev/st0 bs=32k of=scratch #which closes and rewinds the tape
mt -f /dev/nst0 defcompression off
mt -f /dev/nst0 compression off
# the right one varies according to mt version & tape drive.
dd if=scratch bs=32k of=/dev/st0
# which by useing the close and rewind, forces the restored label to 
be flushed to the media, which in turn changes the flag stored on 
the tape to uncompressed.
-------------------
Tune to suit, but thats the general outline.  I was at one time, 
forceing the buffer flush by writing from /dev/zero, enough bytes 
(about 10 megs)  to force the flush, but I don't think thats 
required as all you should need is a dirty buffer which is flushed 
by the close and rewind /dev/st0 does.  Thats the theory anyway :)
And this should be several minutes a tape faster than the forced 
flush using /dev/zero.

>Any help is appreciated.
>
>thanks

-- 
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.