DAT drive I/O error - Hardware

This is a discussion on DAT drive I/O error - Hardware ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: DAT drive I/O error

  1. 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




  2. Re: DAT drive I/O error

    On 2008-05-31, Haines Brown 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


    [...]

    > 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?


    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)

  3. Re: DAT drive I/O error

    John Thompson writes:

    > Have you tried retensioning the tape?
    >
    > I'm not very familiar with DAT drives; can they use cleaning tapes like
    > DLT devices?


    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




  4. Re: DAT drive I/O error

    Note: E-mailed *and* posted.

    In article <8763suz4ez.fsf@teufel.hartford-hwp.com>,
    Haines Brown wrote:
    :After some years backing up to an external USB drive, I would at this
    oint 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"

  5. Re: DAT drive I/O error

    Robert Nichols writes:

    > In article <8763suz4ez.fsf@teufel.hartford-hwp.com>,
    > Haines Brown 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.


    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




+ Reply to Thread