SCSI tape install

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

Hugh Rutledge wrote in a message to Mike Bilow:

 HR> Please don't talk to me about Red Hat.  I just got the
 HR> following message back from them.  All very nice but it
 HR> refers to a non-existent location on the system
 HR> fresh-installed from their 5.2 operating system disk. 

I'm afraid I side with Red Hat on their answer to you, although they made a
serious typographical error that would only further confuse you.

> Host: scsi0 Channel: 00 Id: 05 Lun: 00
>   Vendor: ARCHIVE  Model: Python 04106-XXX Rev: 7270
>   Type:   Sequential-Access                ANSI SCSI revision: 02
> 
> This is the DAT drive we are looking to use.  How do we access it?

If you got as far as that sign-on message, you are 90% there already.

 HR>         The device it's self should show up in /dev/sd0 and
 HR> you should be able to access it using the `mt` and `tar`
 HR> commands.  

Your SCSI tape device is going to show up as /dev/st0 and /dev/nst0.  The
reason for the use of two mirror devices is that the st0 kind will
automatically rewind the tape for you under certain circumstances, while the
nst0 kind will not.  Since both types of operation are often found in Unix tape
software, Linux provides both autorewinding and non-autorewinding access to
accommodate the widest range of software.  Both use the same major device:

3:27 x:~# ls -l /dev/*st0
crw-r-----   1 root     disk       9, 128 Jul 18  1994 /dev/nst0
crw-r-----   1 root     disk       9,   0 Jul 18  1994 /dev/st0

 HR>    This is a configuration and administrative issue and
 HR> doesnt fall under the installation support we can provide.

Tape access requires some minimal configuration, since a fair amount of
software is hardcoded to use /dev/tape, which is assumed to be a symlink to
/dev/nst0 or whatever your real tape device happens to be:

3:27 x:~# ls -l /dev/tape
lrwxrwxrwx   1 root     root            9 Oct 20  1994 /dev/tape -> /dev/nst0

Control of the tape drive itself, as distinct from reading and writing data, is
usually handled by the standard "mt" utility.  This can be compiled for
different configurations, but your best bet is probably to use the one supplied
by Red Hat with your distribution.  Issuing "mt -v" will display the version,
while "mt -h" will list commands are supported by your build:

3:28 x:~# mt -v
mt-st v. 0.5
3:28 x:~# mt -h
usage: mt [-v] [-h] [ -f device ] command [ count ]
commands: weof, wset, eof, fsf, fsfm, bsf, bsfm, fsr, bsr, fss, bss, rewind,
          offline, rewoffl, retension, eod, seod, seek, tell, status,
          erase, setblk, lock, unlock, load, compression, setdensity,
          drvbuffer, stwrthreshold, stoptions, stsetoptions, stclearoptions,
          defblksize, defdensity, defdrvbuffer, defcompression, densities,
          setpartition, mkpartition, partseek, asf.

Here's what an Archive Diamondback (4586) looks like empty:

3:31 x:~# mt -f /dev/tape status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (40050000):
 BOT DR_OPEN IM_REP_EN

Here's what the same drive looks like with a DDS-2 cartridge inserted:

3:32 x:~# mt -f /dev/tape status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x24 (DDS-2).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

For actual reading and writing data, you will need an appropriate utility such
as "tar" or "cpio."  You can also get commercial utilities, such as "bru."  The
use of such utilities is beyond the scope of this message, but there are man
pages for "mt," "tar," and "cpio" with more complete descriptions.

My examples above are pulled from a real, live, running system.  I have been
using and programming tape devices for years under Linux.  They work well.
 
-- Mike


***
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to discuss-request at blu.org