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