DAT drive I/O error

After some years backing up to an external USB drive, I would at this
point like to recover some files copied to 4mm DAT tape in ca. 2001
using bru2000 software. I installed the old drive, inserted a tape, and
experienced an I/O problem:

# mt -f /dev/st0 status
tape drive = Generic SCSI-2 tape
drive status = 318767616
sense key error = 0
residue count = 0
file number = -1
block number = -1
Tape block size 512 Bytes. Density code 0x13 (DDS (61000 bpi )).
Soft error count since last status=0
General status bits on (10100000):
ONLINE IM_REP_EN

# mt -f /dev/st0 tell
At block 0.

# tar -tvf /dev/st0
tar: /dev/st0: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now

Having no reason to assume that tar could manipulate data on a BRU2000
tape, I installed an old copy of BRU2000 I had kicking around and get:

# bru -t
bru: [W130] warning - read error on first block: errno = 5,
Input/output error
bru: [A121] load volume 1 - press ENTER to continue on device
'/dev/st0'

The tape drive is on a different SCSI bus than my HD. The bus is
terminated. I tried different tapes, but no difference. No log error
reports.

An obvious issue is head cleaning. so I blew out the drive bay, wiped
the head with some isopropyl, but was unable to locate the optical
sensor in the drive bay.

Are there things I might do to pin down just what is causing the I/O
error?

Can anyone help me identity the optical sensor in the WangDAT 3100 so
that I might clean it?

I did the backups with BRU2000. Does that mean that tar can't extract
the data from the tape?

Can I use dd to copy the contents of the tape onto HD and then untar
them from there?

--

Haines Brown, KB1GRM

On 2008-05-31, Haines Brown <brownh@teufel.hartford-hwp.com> wrote:
[color=blue]
> After some years backing up to an external USB drive, I would at this
> point like to recover some files copied to 4mm DAT tape in ca. 2001
> using bru2000 software. I installed the old drive, inserted a tape, and
> experienced an I/O problem:
>
> # mt -f /dev/st0 status
> tape drive = Generic SCSI-2 tape
> drive status = 318767616
> sense key error = 0
> residue count = 0
> file number = -1
> block number = -1
> Tape block size 512 Bytes. Density code 0x13 (DDS (61000 bpi )).
> Soft error count since last status=0
> General status bits on (10100000):
> ONLINE IM_REP_EN[/color]

[...]
[color=blue]
> Are there things I might do to pin down just what is causing the I/O
> error?
>
> Can anyone help me identity the optical sensor in the WangDAT 3100 so
> that I might clean it?[/color]

Have you tried retensioning the tape?

I'm not very familiar with DAT drives; can they use cleaning tapes like
DLT devices?

--

John (john@os2.dhs.org)

John Thompson <john@vector.os2.dhs.org> writes:
[color=blue]
> Have you tried retensioning the tape?
>
> I'm not very familiar with DAT drives; can they use cleaning tapes like
> DLT devices?[/color]

I tried retensioning, but I am uncertain it is taking place. No sound;
no flashing LED. However, I don't recall after all these years whether I
had those symptoms. After the command I'm taken back immediately to a
prompt. I suspect the drive is not transporting tape.

I ordered a DDS cleaning tape, but it has not arrived yet. It is my
assumption that they are good for routine cleaning, but what really
needs to be done is the dust blowing and isopropyl swab approach.

I gather the optical sensor should look like a red LED, but I don't see
any such thing in my WangDAT 3100 drive. The company (Tecmar) apparently
is defunct, and I'm not able to locate any physical spec sheet that
points to the location of the sensor. The drive is fairly common, and I
was hoping someone here might know.

I see that these drives are now available quite cheaply, and if I knew
the drive was broken I'd just replace it. However, I don't know this for a
fact. I was trying to find out whether the symptoms I described, if they
occurs with different tapes, definitely points to a hardware problem.

--

Haines Brown, KB1GRM

Note: E-mailed *and* posted.

In article <8763suz4ez.fsf@teufel.hartford-hwp.com>,
Haines Brown <brownh@teufel.hartford-hwp.com> wrote:
:After some years backing up to an external USB drive, I would at this
:point like to recover some files copied to 4mm DAT tape in ca. 2001
:using bru2000 software. I installed the old drive, inserted a tape, and
:experienced an I/O problem:
:
: # mt -f /dev/st0 status
: tape drive = Generic SCSI-2 tape
: drive status = 318767616
: sense key error = 0
: residue count = 0
: file number = -1
: block number = -1
: Tape block size 512 Bytes. Density code 0x13 (DDS (61000 bpi )).
: Soft error count since last status=0
: General status bits on (10100000):
: ONLINE IM_REP_EN
:
: # mt -f /dev/st0 tell
: At block 0.
:
: # tar -tvf /dev/st0
: tar: /dev/st0: Cannot read: Input/output error
: tar: At beginning of tape, quitting now
: tar: Error is not recoverable: exiting now

Tar is going to get nowhere because its trying to read its default
blocksize of 10240 bytes while the drive blocksize is fixed at 512
bytes. That's an instant I/O error. You need to run

mt -f /dev/nst0 setblk 0

to put the drive in variable blocksize mode. I would hope that bru is
smart enough to do that on its own, but I've never used bru, so that
could be the problem there as well.

--
Bob Nichols AT comcast.net I am "RNichols42"

Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> writes:
[color=blue]
> In article <8763suz4ez.fsf@teufel.hartford-hwp.com>,
> Haines Brown <brownh@teufel.hartford-hwp.com> wrote:
> : # tar -tvf /dev/st0
> : tar: /dev/st0: Cannot read: Input/output error
> : tar: At beginning of tape, quitting now
> : tar: Error is not recoverable: exiting now
>
> Tar is going to get nowhere because its trying to read its default
> blocksize of 10240 bytes while the drive blocksize is fixed at 512
> bytes. That's an instant I/O error. You need to run
>
> mt -f /dev/nst0 setblk 0
>
> to put the drive in variable blocksize mode.[/color]

Bob, I didn't realize that setblock 0 would put the tape drive in
variable block size. However, it didn't seem to do anything for me:

# mt -f /dev/st0 setblk 0

# mt -f /dev/st0 seek 2
mt: /dev/st0: Input/output error

# tar -tvf /dev/st0 /dev/st0
tar: /dev/st0: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now

I tried setblock 512. I tried another tape. I tried another DAT drive
without luck.

If mt is used to set the block size, where is that information stored,
as indeed it must be if a subsequent command depends on it. Is it stored
persistently until changed?

I had originally used a SCSI adapter that is probably not supported in
Linux, and changed to an Adaptec 2906. I don't believe it is in the
hardware database, but an exploration online suggests that it works with
Linux, and I gather it probably uses the Adaptec module aic7xxx, which
is also being used by my principal SCSI adapter (Adaptec 3940).

How do I know the card is actually using this driver? For example, in
dmesg, I find that scsi0 is using the AIC7XXX module to read information
about my tape drive (WangDAT 3100). Does that mean the aic7xxx module is
the right one for the adapter and is loaded for the tape drive as well
as for my principle adapter (scsi1 and scsi2 for its two channels)?

In /proc/scsi/device_info, my tape drive is listed three times, as Model
2600, 3200, and as Model 1300, while my drive is actually 3100 (where it
is listed as such in dmesg). However, in /proc/scsi/scsi, scsi0 is tied
to my tape drive, with correct model number: WangDAT 3100,

--

Haines Brown, KB1GRM