Very Computer

I've spent a couple hours of quality time with Google and haven't
solved my trouble.  I used to be able to read from my SCSI tape
drive, but I haven't tried that in a long time.  Now that I need
to read a tape, because I erase a file that I need, I can't read
my backup tape.

When I set my block size to variable like this:

    mt -f /dev/st0 setblk 0

Then my tape status becomes:

    SCSI 2 tape drive:
    File number=0, block number=0, partition=0.
    Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
    Soft error count since last status=0
    General status bits on (45010000):
     BOT WR_PROT ONLINE IM_REP_EN

And tar works fine with these commands:

    tar cvf /dev/st0 file1 file2 file3
    tar tvf /dev/st0
    tar xvf /dev/st0

When I try to recover with BRU (using variable block size), like this:

    bru -x /my/path/file

I get this error:

    warning - read error on first block: errno = 12, Cannot allocate memory

I look in the BRU log from when the archive was written and find:

    buffer size = 500k bytes

So, I set the block size like this:

    mt setblk 500000

Once again status shows:

    SCSI 2 tape drive:
    File number=0, block number=0, partition=0.
    Tape block size 500000 bytes. Density code 0x13 (DDS (61000
    bpi)).
    Soft error count since last status=0
    General status bits on (45010000):
     BOT WR_PROT ONLINE IM_REP_EN

Which tells me that my block size should match what's on the tape.
Again, I try to recover my file.

    bru -x /my/path/file

This time my error message is:

    warning - read error on first block: errno = 5, Input/output error

I saw a lot of discussion in Google about the SCSI tape driver(s)
being changed in the kernel when moving from 2.2 to 2.4.
Specificly block size handling of variable block size was
changed.  I don't follow the whole thing, partly because it's
hard to pick up on context in google fragments, and partly
because I just don't know what goes on in the tape drivers.

I sure would like to be able to read my archive tapes.  Anyone
got a suggestion?

Thanks much....

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

I have Red Hat 7.3 running with an Ecrix VXA-1 tape drive on a SCSI host
adapter. If I say nothing about setblk, I see:

valinux:root[/home/jdbeyer/SECURITY]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x80 (DLT 15GB uncomp. or Ecrix).
Soft error count since last status=0
General status bits on (45010000):
  BOT WR_PROT ONLINE IM_REP_EN

If I then do:

valinux:root[/home/jdbeyer/SECURITY]# mt -f /dev/st0 setblk 0
valinux:root[/home/jdbeyer/SECURITY]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x80 (DLT 15GB uncomp. or Ecrix).
Soft error count since last status=0
General status bits on (45010000):
  BOT WR_PROT ONLINE IM_REP_EN

If I do a little test on a BRU tape:

#!/bin/bash
BRU=/bin/bru
MT=/bin/mt
TAPE_DRIVE=/dev/st0
mt -f $TAPE_DRIVE setblk 0
# Now verify it.
$BRU -g

I see:

label:          Tuesday10
created:        Tue Mar 11 01:13:39 2003
artime:         1047363219
archive_id:     3e6d7e933f40
volume:         1
writes:         78
release:        17.0
variant:        0
bufsize:        65536
msize:          0
msize_blks:     0
serial_number:  8250-7847
device:         /dev/st0
user:           root
group:          root
system:         Linux valinux. 2.4.18-2 #1 SMP M i686
bru:            i686-linux-gnu
command_line:   /bin/bru -c -L Tuesday10 -V -B -X /

I doubt it has much to do with the tape drivers. More likely that your
/etc/brutab file may have changed since you wrote the tapes. I cannot
test that easily because my old tapes are in the bank, and it will not
open for a few hours and I am not going there anyway. The main problem
is that if you change the buffer size in /etc/brutab between when you
write the tapes and when you read them, I am not sure what will happen.
I had trouble with this before I started ALWAYS setting

mt -f /dev/[n]st0 setblk 0

because if you do not set it, you get whatever the system used when it
wrote the tape. And I think blocksize is 1024 bytes, or something like
that, and if BRU thinks it is 50000 bytes and the driver thinks it is
1024, I think it reads the first 1024 bytes of each block. This is not
the whole answer, because I went through this about 2 years ago, and I
do not remember it anymore. That was when I was running R.H.L. 6.2 or
something like that. So I am sure it is not the drivers.

The funny thing is that if you run BRU normally, the check phase will
work because whatever block size the tape was really using will be the
same in both phases, but it may be different next time. That is why it
is important to use the setblk, so that it is the size BRU is expecting
based on the contents of /etc/brutab.

Have you looked at your /etc/brutab? Here is mine.

# These look funny, but global parameters are defined with
# "#+" (pound-plus) syntax.  If you wish to comment them out,
# insert anonther #. E.g. "# #+..."
# #+MOUNTCMD=/bin/mountcmd.sh
#+MOUNTCMD=/etc/BRUmountcmd.sh
# #+UNMOUNTCMD=/bin/unmountcmd.sh
#+OVERWRITEPROTECT=yes
#+MAXWRITES=500
#+RECYCLEDAYS=6

# The first device listed will be the default device.

/dev/st0 devname="'VXA-1 Ecrix Drive'" \
   size=0 bufsize=64k  \
   tape rewind autoscan

/dev/nst0 devname="'VXA-1 Ecrix Drive'" \
   size=0 bufsize=64k  \
   tape norewind noautoscan \
   fmtcmd="mt -f /dev/nst0 erase" \
   rfmcmd="mt -f /dev/nst0 fsf" \
   bfmcmd="mt -f /dev/nst0 bsfm 2" \
   retencmd="mt -f /dev/nst0 reten" \
   rewindcmd="mt -f /dev/nst0 rewind" \
   eodcmd="mt -f /dev/nst0 eod"

# Bit bucket for testing
/dev/null bufsize=32k norewind noautoscan

# Entry for stdin/stdout -- DO NOT PUT FIRST
- bufsize=32k norewind noautoscan

All my BRUmountcmd.sh says is:

#!/bin/bash
###############################################################################
#
       #
#  mountcmd.sh          sample script for MOUNTCMD                            #
#
       #
#     If the MOUNTCMD variable is set, this command will be called
BEFORE     #
#     BRU attempts to read or write a tape.
       #
#
       #
#     Please modify this script to suit your own needs.
       #
#
       # #
                #
###############################################################################

###############################################################################
#
       #
#     Just do the required mt -f /dev/{n}st0 setblk 0 command. [jdbeyer]
      #
#
       #
###############################################################################

MT=/bin/mt

CMD=$0          # name of this command

DEV=$1          # 1st parameter is device name
VOL=$2          # 2nd parameter is expected volume number
MODE=$3         # 3rd parameter is BRU mode letter
MSIZE=$4        # 4th parameter is media size in Kbytes

case "$MODE" in
      c ) :
        #----------------------------------------------------------
        # Replace the following lines with any commands that      |
        # should be called before BRU attempts to WRITE to a tape |
        #----------------------------------------------------------

#       echo "$CMD: volume $VOL on device $DEV (mode = $MODE)"
        $MT -f $DEV setblk 0
        RTN=$?          # set return code
        ;;

     [idtgx] ) :
        #----------------------------------------------------------
        # Replace the following lines with any commands that      |
        # should be called before BRU attempts to READ a tape     |
        #----------------------------------------------------------

#       echo "$CMD: volume $VOL on device $DEV (mode = $MODE)"
         $MT -f $DEV setblk 0  
        RTN=$?          # set return code
        ;;
esac

exit $RTN       # return 0 if successful

--
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine    73926.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 7:40am up 1 day, 21:08, 2 users, load average: 2.82, 2.49, 2.29

I fixed this:

    warning - read error on first block: errno = 12, Cannot allocate memory

By running:

    mt -f /dev/[n]st0 setblk 0

I fixed this:

    warning - read error on first block: errno = 5, Input/output error

By adding the "-b 500k" option to my BRU command line like so:

    bru -vvvv -b 500k -x /home/file/to/restore

Oddly enough my /etc/brutab file was updated on Feb 1st, and the
archive I'm reading was written on Mar 7th, so it must have used
the existing brutab.  Compounding this is the incbru script,
which turns out to have "-b 500K" included in the BRUOPTS
variable, which doesn't match the brutab, thereby causing the
problem.

Looks like I've got some work to do forcing consistency between
the scripts and brutab.  I'll likely just let everything use
what's in brutab -- seems safest.

Thanks!

--
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.