On Friday 31 January 2003 09:14, lone_wolf_20 AT yahoo DOT com wrote:
>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.
The idea was that if *that* tape had ever been used in the
compressed mode, somethng along the lines of what I described will
be required to fix it. If amanda runs the robot, the tape
recognition stuff will function from within amdump, and you will
not have a chance to fix it with an mt command then.
For brand new tapes, I'd expect that to be moot. YMMV of course.
>--- 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
>[This E-mail scanned for viruses by Declude Virus]
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.22% setiathome rank, not too shabby for a WV hillbilly
|
