Subject: Re: DLT Tape drive issues (was dump is slow...)
To: Aaron J. Grier <agrier@poofygoof.com>
From: Louis Guillaume <lguillaume@berklee.edu>
List: netbsd-users
Date: 12/05/2006 11:28:08
Aaron J. Grier wrote:
> On Wed, Nov 29, 2006 at 11:47:28PM -0500, Louis Guillaume wrote:
>> What do you use for the density code? I used `85', which is supposed
>> to be 70G compressed according to the manual. But that's supposed to
>> be in hex. And I have no idea what "mt setdensity xx" is supposed to
>> use; 85 or 133. Both are accepted.
>
> looking at the source of mt, the numbers are all base 10. so 133 is the
> correct one to use. what do the indicators on the drive show after you
> do the "mt -f /dev/nrst0 setdensity 133" ?
>
Unfortunately, I don't have a drive case with the indicators! The drive
I have was inherited from the day job; looks like they didn't spring for
the case with indicators.
I have it set to 133 and it seems to be ok.
>> Anyway, I did an "mt erase" and all hell broke loose. The drive had
>> some bad-looking errors (see below) and it caused the system to hang.
>
> was this on the block or raw device? I've run this command before. it
> works, but takes a LONG TIME to run and can't be interrupted.
>
raw device. Haven't attempted this again! I've done this successfully on
other tape drives (forget the model but DDS2) with no problem.
>> What about the tape device? How come we use the raw device /dev/nrst0
>> rather than the block device /dev/nst0???
>
> for the gritty details, "man 4 mtio"
>
> the block device is never used in practice.
>
Thanks, that's very helpful.
>> st0: 65536-byte tape record too big for 32768-byte user buffer
>> st0(ahc1:0:5:0): Check Condition on CDB: 0x08 00 00 80 00 00 SENSE
>> KEY: No Additional Sense Incorrect Length Indicator Set INFO FIELD:
>> -32768 COMMAND INFO: 11700 (0x2db4) ASC/ASCQ: No Additional Sense
>> Information
>
> the tape returns 64k of data, but the device driver only has 32k of
> space. not sure why that should cause the controller to die, though.
Actually I don't think this was the problem. It was just in the buffer
and I pasted it with the messages from the controller-failure. I think
these are from trying to run "restore" with the wrong block size.
I suspect that the tape length couldn't be figured out. I usually have
eew turned on so that it will detect, but maybe it was off at the time.
But I figure the "erase" function is implemented in the device itself,
not in the driver.
We'll see what happens towards the end of the tape anyway...
Thanks for the help,
Louis