Thanks for the responses.  If I can get my boss to buy
off on the rig, I'll post the tapeinfo results for the
drive.

Thanks for the heads up about the compression as well.
 I saw this in one of the other posts to the group
during the search for info on the drive.  I'll have
the compression off on the hardware prior to doing any
labeling / tapeinfo runs which should prevent the
erratic behavior.

--- Gene Heskett <gene_heskett AT iolinc DOT net> wrote:
> On Thursday 30 January 2003 18:09, Jason L Tibbitts
> III wrote:
> >>>>>> "lw" == lone wolf <lone_wolf_20 AT yahoo DOT com>
> writes:
> >
> >lw> 2) Has anyone used the SDLT 320 drives w/
> Amanda?  I searched
> > the lw> group archives and didn't get much from
> them on these
> > drives, same lw> with the FAQ (tape-info would be
> nice for these
> > drives).
> >
> >I have an SDLT220 drive; it works just fine.  The
> only issue I
> > have is with compression: I do software
> compression but I can't
> > seem to get the drive to turn off its internal
> compression
> > properly.  This seems to result in erratic tape
> capacity.
> 
> This sounds as if that drive type uses a scheme
> similar to the DDS 
> drives use, wherein the compression state in effect
> when that tape 
> was first written, is recorded in a hidden header
> only the drive 
> can access. So when a tape that been compressed
> before is 
> re-inserted and recognized, even if the dip switch
> setting is off, 
> it will turn the compression back on in the process
> of recognizing 
> the tape.
> 
> For a DDS drive, one must use mt to turn it off, and
> then force 
> enough data to the drive to cause it to have to
> flush the buffers 
> to tape.  This then will rewrite that hidden header
> with the 
> compression flag bits turned off, and you should
> then have an 
> uncompressed tape.
> 
> To preserve the tape label, do it something like
> this, commands 
> adjusted for your environment of course.
> 
> mt -f /dev/device rewind
> #save the tapes label
> dd if=/dev/device of=scratch bs=32k
> mt -f /dev/device rewind
> # shut the compression off
> mt -f /dev/device compression off
> # now force a buffer flush to update the flags
> dd if=/dev/zero of=/dev/device bs=32k count=100000
> mt -f /dev/device rewind
> # restore the tapes label
> dd if=./scratch of=/dev/device bs=32k
> mt -f /dev/device rewind
> 
> One could clean this up and make it work then put
> this into a script 
> and run it 30 minutes before amdump is fired off.
> 
> >lw> 3) I am planning on using a Linux box (running
> RedHat 8.0)
> > with lw> sufficient power to do software
> compression.
> >
> >Well, I back up a couple of terabytes of disk to a
> single SDLT220
> >drive without problems; the dumps can sometimes
> take six hours or
> > so but they're always finished by the morning.
> 
> -- 
> Cheers, Gene
> AMD K6-III@500mhz 320M
> Athlon1600XP@1400mhz  512M
> 99.22% setiathome rank, not too shabby for a WV
hillbilly


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com