• Please review our updated Terms and Rules here

Tapes: A few pointers when using SCSI/IDE tape drives on Debian Linux

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
44,227
Location
Pacific Northwest, USA
While I'm doing a bunch of tape work today, I thought I'd pass on some useful hints.

First off, you really need to install the following packages: mt-st mtx lsscsi
The first, mt-st, changes the "mt" command to support lots of additional options not present in the stock version. If you're going to write tapes, you need the capabilities.
The second, mtx, contains the "scsitape" utility. I recently had to retrieve data from an 8mm tape that consisted of many files, each file starting with a 244-byte block, followed by 404 blocks of 6164 bytes. The standard "dd" utility isn't set up for this, but scsitape can transfer arbitrarily-sized blocks and this is what I used.
The third, lsscsi, is useful for finding out where devices are. In particular, the "scsitape" utility requires not the name of the block device (e.g. /dev/st0), but its generic SCSI conntection (/dev/sgX).

To make life easy, you probably should set the environment variable TAPE to the device name. Since I want control over tape positioning, I don't what automatic rewind at device close. For example, if the basic device is /dev/st1, I use /dev/nst1, which inhibits auto-rewind. So, to set the TAPE variable to this, I do:

Code:
TAPE=/dev/nst1
export TAPE

Scsitape requires a generic scsi device name, so "lsscsi -g" might give an output like this:

Code:
[0:0:6:0] tape EXABYTE EXB-8505 0052 /dev/st1 /dev/sg4

Scsitape requires that you explicitly supply the generic scsi device, so you'd use "scsitape -f /dev/sg4 command" to access the drive. Here's an example of how to use the "command" part:

I'm given an 8mm (Exabyte) tape from some sort of data collection setup. Said tape has no directory structure but is made up of many files consisting of one record of 244 bytes and 404 records of 6164 bytes (yes, Virginia, such things exist!). The standard utility "dd" is not set up to handle something like this, so it's scsitape. Note that since this is accessing a low-level interface, you have to have superuser privileges. To get a single file, I'd run the following:

Code:
sudo /sbin/scsitape -f /dev/sg4 read 0 1 >file1.hdr
sudo /sbin/scsitape -f /dev/sg4 read 0  >file1.dat

The result would be two files, one of 244 bytes and the second of 2,490,480 bytes. For the remainder of the tape, write a bash script to generate names and run until no more data is transferred.

If you do use "dd", note that dd transfers a single block of data in blocking mode as default behavior. On a streamer tape, this can be horrible, with the drive "shoe shining" after every block or so, particularly when writing. This is why you really need the "mt-st" package. Let's suppose that we're using the TAPE variable set up at the beginning of this past and we want to write a tape. The first task is to load a tape in the drive. Since I'm writing a tape with 512 byte blocks and want to do it at the highest density my EXB-8700 drive will support, I set things up this way:

Code:
mt setblk 512
mt setdensity 21

The "setblk" is pretty obvious, but where did I get the number for the "setdensity". Unfortunately, this is where you have to do some digging. Tandberg Data, who owns Exabyte, has published a document that gives the various setting of the density argument--they're unlikely to be shared with non-Exabyte devices.

After having set the density and physical block size, I can perform my copy onto the tape:

Code:
dd if=myfile of=$TAPE bs=1M

Why the "bs" specification? We already have instructed the low-level SCSI driver to write 512 byte blocks, so we can speed things up considerably by doing our I/O in megabyte chunks, which avoids "shoe shining".

Finally, we can rewind the tape and unload it from the drive:

Code:
mt rewind
mt eject

For those of you trying to get a handle on Linux and tapes, I hope this will get you started.
 
Last edited:
Man, I haven't touched tape drives since... geeze, 2003? The company gave me enough money to buy a 20-slot LTO tape jukebox from Dell... and no more, so I pieced a clattering zombie of a backup system together using a Linux host. I was proud of it at the time but I don't think I can remember a thing about how I set it up or what software I used. (Finding something to run the tape robot felt like an achievement at the time.)
 
It always amused me that the original Star Trek TV series kept referring to "tapes". Lack of prescience, I suspect. Still, in 1966, we were still spinning a lot of tape (and cards). :)
 
When I was a kid it bugged me that so many people insisted on referring to Atari 2600 cartridges as "tapes". (I mean, seriously, even grade schooler could tell you there wasn't any tape in those things. Maybe it was a regional thing?) ;) Apparently the idea of calling a removable storage cartridge of any sort a "tape" was well engrained in the collective consciousness for a long time.
 
Consider the 60's-70's TV shows showing "computers". A few started out with unit-record gear (e.g. sorters, printers), then moved to blinkenlights and spinning tapes. A few showed only tape drives. Eventually CRT displays.

Star Trek TOS and tapes
 
Last edited:
Star Trek TOS did a fair job of emulating the look of near future computer hardware. The end result does make it appear that after the couple of wars in the future history that the technology base was reduced to the Kenbak-1 reading Zip disks.
 
Tape backup is no longer affordable for most home users (anything new is more expensive then dumping it on another drive or the cloud).
 
people at home never did backups, which is why just having some invisible hand take care of it for you is now the way things are.
 
Back
Top