APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Tapes and Tape Drives

© September 1998 Tony Lawrence

This primarily deals with tape drives on SCO Unix. Some of this may be helpful for general concepts, but its primary focus is SCO. Other articles on this site deal with Linux and other OS specifics.

See also Tape or CDROM not found

First: tape devices are not mounted. You simply read or write to the device (tar cvf /dev/rct0 . ).

The default SCSI tape on SCO would be /dev/rStp0, and that may be linked to /dev/rct0 (default cartridge tape). See "man tape" for details. SCO systems do not use the "mt" command; use "tape" instead ("tape status", for example).

Another common misconception is how big a file can be written to tape. While a file system will have file size limits (old systems were limited to 2GB, for example), tape is only limited by how long it is and how dense the magnetic fields can be packed.

Dependent upon the OS and file system in use, an individual file and sometimes even entire file systems can be limited. That's not at all uncommon, in fact. Nor is it unusual to have a file system that may support terabytes but have individual files still stuck at as little as 2GB.

When the OS and file system do support larger sizes, some utilities will still have limitations just because they expected those limitations so the programmer saw no need to store numbers in more bits. Therefore it is also not unusual to have an OS and FS that supports much larger files and yet still find certain utilities that will fail if invoked on files larger than some limit.

See Large File Support in Linux if interested.

Topics covered here:

How do I know what host adaptor to choose?

Tape can't be accessed- device is busy

tape: can't open '/dev/xct0':No such device

DAT tape doesn't eject

I've over-written my tape!

How to add the tape drive

Various relinking problems on 5.0.X

Retensioning, formatting, erasing

Tapes from other systems/drives

How do I know what host adaptor to choose?

If the tape is connected to the same adaptor your hard drives connect to, then what "mkdev tape" comes up with as default is the right choice. If not, then you have to figure it out by choosing from the adaptors listed in /etc/default/scsihas

Tape can't be accessed- device is busy

This could be defective hardware, but it can also just be that you have accidentally or otherwise installed Arcserve.

By default, Arcserve claims the tape device for it's own. If Arcserve is what you intend to use for backups, that's great. Otherwise, you'll need to disable it, temporarily or permanently.

To disable it permanently, you'll need to remove or edit (by adding an exit 0 at the beginning of the file) the /etc/rc2.d/S69ARCserve. To stop the server temporarily (for example, because you want to do a simple cpio backup or restore) use astop. It shouldn't be a big surprise to learn that astart will start it up again.

You can also edit /usr/lib/ARCserve/tapesvr.cfg and remove the semicolon before NO_DEVICE_LOCKING - doing this lets ARCserve run but prevents it from taking control of the tape.

If that's not the problem, and the symptoms are that you access the tape and it hangs, and you can't kill the process and only rebooting will fix it, then you have a hardware problem- broken drive, scsi cable or termination, misconfiguration- something.

How to add the tape drive

You add a tape drive by running "mkdev tape". This asks questions about the type of tape and its configuration. If you have more than one tape drive, you may want to make one of them the "default"- all that means is that /dev/rct0 and /dev/xct0 will be linked (using "ln") to point at that tape. If you have a SCSI tape drive, but aren't sure about its configuration, you can use "sconf" on modern releases (don't use this prior to OSR5.0.5 - it existed, but could crash your system). Here's the output of "sconf -v" on one of my machines:

Sdsk    alad    0       0       0       0
Sdsk    alad    0       0       1       0
Stp     alad    0       0       3       0
Sdsk    alad    0       0       4       0
Srom    alad    0       0       6       0

This shows me that the tape (Stp) is attached to an "alad" controller and is at id 3. Specifically, reading left to right, it's "alad unit 0, bus 0, id 3, lun 0".

See also Tape or CDROM not found

Various relinking problems on 5.0.X

Plainly there are problems with mkdev tape on 5.0.x. The /etc/conf/pack.d/Stp/space.h file gets munged badly and then you can't relink. Various SCO technical articles reference this:





and there are more.

I suggest having a safe copy of the /etc/conf/pack.d/Stp/space.h file to save you time should this happen to you.

Most of the time, this seems to happen if you do not delete the default tape drive that the install configured, though I have heard of it getting messed up in other circumstances.

DAT tape doesn't eject

Pushing the eject button doesn't work.

First, check that no process is using the tape:

fuser /dev/rStp0

If that's not the case, the tape may have been misconfigured. Run mkdev tape and be sure that it knows that this is a DAT and not a Generic. It's easy to make that mistake when running 'mkdev tape': follow the prompts carefully and press "ENTER" for the defaults until you get to the menu that askes what kind of tape it is.

I did once have a DAT tape that would not eject without rebooting, but I couldn't find any reason for it, so we replaced it. I took the unit to another machine (same OS and version), and there it would eject fine, but then you couldn't put a new tape in without rebooting, so it didn't help much!

For a scsi tape that ejects when you DON'T want it to, remove /dev/rStp0 and "mknod /dev/rStp0 c 46 4".

Jeff Liebermann points out:

HP drives have a not-so-secret method of ejecting the tape when busy. Punch the button 3 times, wait 45 seconds, and out it comes. It's somewhere in the C1533A and C1537 manuals.

tape: can't open '/dev/xct0':No such device

Using "tape status" (or any "tape" command) doesn't work and complains with this message.

This could simply mean that this is not your default tape drive.

If you can tar cvf /dev/rStp0 . (or rStp1 if this was the second drive), but cannot do "tape" commands, then run mkdev tape again and select the default tape drive. Or for a quicker test:

rm /dev/xct0
mknod /dev/xct0 c 46 128  (assuming rStp0)

and then try "tape status" etc.

What's happening here is the tape commands use ioctl calls to query the tape device. Ioctl commands are just special commands that a device driver can use to get information from a device. Most drivers are written to recognize a special minor number as the ioctl device; this simplifies the driver and allows any data to be written to the ordinary device.

For tapes, the minor number for ioctl is 128. The ioctl devices are /dev/xct0, /dev/xStp0, etc. If you have created a SCSI tape, but didn't set it as default, then the /dev/xct0 is

crw-r--r--   1 root     sys       10,128 Sep 13 10:35 /dev/xct0

which has the right minor number, but the major (10) is for a cartridge tape, not SCSI.

You could fix this as suggested above, or by editing /etc/default/tape and changing the

device = /dev/xct0


device = /dev/xStp0

Retensioning, formatting, erasing

Various tape commands work with different types of tapes. Some tapes require formatting, some have the ability to be retensioned, some don't. You can get a list of tape commands by typing

tape 2>&1 | more

or man tape

Tapes from other systems/drives

A DAT tape is a DAT tape, right? If you used cpio to create a tape on System A, you should be able to read it with a different DAT on system B. Yes, but..

The first problem you can run into is hardware compression. Different manufacturers can use different schemes. Therefore, if you are planning to transfer to another system, you want compression turned off. To do that on OSR5, you'd say

tape -a 0 setcomp 

Another area of problem is hardware block size. The defaults can vary, so you need to explicitly set it to match. To find out what the block size is, do:

tape getblk

(note- you may need a tape in the drive to do this!)

Once you know, you can set it to match on the other machine:

tape -a 0 setblk
tape -a 512 setblk

There is also the issue of tapes set to variable block size vs. fixed block size. A tape made on a variable block drive cannot be read on a fixed block drive UNLESS both systems used a tape block factor of 2. That's the blocking factor used in your tape command, not the "setblk" size.

What's the difference? A fixed block drive always writes the same number of bytes each time. If you send a larger number of bytes, it gets broken up into multiple writes. Variable means that the tape writes what data it is sent.

Fixed block sizes could be 512,1024 or 2048.

SCO 3.2v4.2 used fixed by default, OSR5 uses variable.

See "Special Considerations" at (link dead, sorry) Exabytes' "Integrating a Tape Drive into a Linux System "

See Reading SCO tapes on Linux.

This newsgroup post offers some other useful information. I was unable to find the original:

From: "D. Thomas Podnar" <tom@microlite.com>
Subject: Re: SCSI tape drives - DDS - OBDR & Stuff
Date: Thu, 26 Jul 2001 16:47:13 GMT

It looks like it is time to add a little information on DDS tapes and
also on OBDR (One Button Disaster Recovery) technology to this thread.

NOTE: There is personal opinion strewed in with objective fact here.
      The reader should be able to discern where I digress.


The original "DAT" drives were just that. They used DIGITAL
AUDIO TAPE. There were no standards, and vendors tended to use
different compression methods. Cross vendor compatibility was almost

Then the vendors got together and picked standards for media, read/write
and compression methods. These were called DIGITAL DATA STORAGE, or
DDS for short. Data could be written on one drive and read on another
quite freely, with three exceptions...

1) DDS 1 head alignment problems caused some incompatibility.
2) A few DDS1 and DDS2 drives were available without the compression
   chip. These couldn't read compressed tapes.
3) Vendors chose default hardware block sizes, and then OSs sometimes
   overroad the defaults. For the record, HP DDS drives tend to default
   to variable block mode (block size=0) while most other vendors tend
   to default to a fixed block size of 512 byes. Reading between them
   is usually simply a matter of matching the block size.

DDS had four generations - DDS1 through DDS4. As someone mentioned,
plans for a DDS5 have been cancelled.

Capacities (Uncompressed)
DDS1 -  60 Meter -  1,300MB -  1.3GB
DDS1 -  90 Meter -  2,000MB -  2.0GB
DDS2 - 120 Meter -  4,000MB -  4.0GB
DDS3 - 125 Meter - 12,000MB - 12.0GB
DDS4 - 150 Meter - 20,000MB - 20.0GB

Note that tape length is not scalable, as each mode writes at a
different density.

Higher densities write faster than lower densities, although if you
put a lower density tape in a higher density drive, it will operate
at the slower speed.

In any event, DDS3 and DDS4 are fast enough that the speed limit on them
is usually the limit that systems provide data to them.

For instance, the HP DAT40 is capable of writing at 360MB/min in compressed
mode (6MB/sec) but most people can't send it data that fast. Seagate claims
330MB/min and I'm sure the Sony spec is similar. All are wonderful devices.

250-300MB/min is typical for a single hard drive system.


 o A DDS1 drive can ONLY Read/Write DDS1 tapes.

 o A DDS2 drive can Read/Write DDS1 or DDS2 tapes.

 o A DDS3 drive can Read/Write DDS1, DDS2 and DDS3 tapes.

 o A DDS4 drive can NOT USE DDS1 60 meter tapes.
 o A DDS4 drive can Read Only DDS1 90 meter tapes.
 o A DDS4 drive can Read/Write DDS2, DDS3 and DDS4 tapes.

In my personal opinion...

DDS1 and DDS2 products needed a lot of work. Head technology was
not up to snuff, and people had problems. Lots of tape drives
got replaced by vendors.

DDS3 drives not only had better capacities and performance, they were
far more reliable.

DDS4 is a great technology. Fast AND reliable, and you can use DDS2 and
DDS3 tapes if your capacity needs aren't as great.

BACKGROUND - OBDR(tm) - One Button Disaster Recovery Technology

Most RISC based systems are capable of booting from any SCSI device,
including tape. They aren't fettered by the limitations of Intel PC
architecture design.

Hewlett Packard decided a while back to see what they could do to
make that capability available to the PC world. By then it had progressed
to the point where PC bioses and SCSI host adapter bioses could boot
directly from a CD-ROM.

I don't claim to know their exact though process, but someone must have
decided that CD-ROM emulation was the least painful method of making
bootable tapes.

The OBDR concept is quite simples.

1) Make the computer system THINK that the tape drive is a CD-ROM.
2) Boot SOMETHING from the "CD-ROM".
3) Turn the CD-ROM Back into a tape drive again to recover your data.

On an OBDR compliant drive, if you power it off, then hold down the
EJECT button while powering it on, its bios will report to the PC and
SCSI host adapter bios that it is a CD-ROM, not a tape drive.

It will then load the equivalent of a CD-ROM boot track into its memory
cache. The PC will boot from it as if it were any normal CD-ROM.

Hewlett Packard currently has an OBDR Compliant bios in the following 

SureStore DAT 24 12/24GB DDS drive
SureStore DAT 40 20/40GB DDS drive
SureStore DAT 40x6 6 tape desktop autoloader

Ultrium 215 100/200GB LTO drive (Half Height)
Ultrium 230 100/200GB LTO Drive (Full Height)

A host adapter and motherboard BIOS capable of booting from SCSI
CD-ROMs (Adaptec, Symbios etc.) is also required. There is no special
"bootable tape" bios requirement.

I'm sure we'll be seeing other announcements on this technology, as
it is useful and exciting.

Now, to BE useful, you need software that works with the OBDR capabilities.

The first vendors to sign on to support OBDR were all Windows / NT vendors.

In the fall of 1999, Two vendors (Microlite and EST) began supporting
OBDR based crash recovery under Linux.

In the fall of 1999, One vendor (Microlite) began supporting OBDR
based crash recovery under UnixWare 7.1.

In August 2001, at least one vendor (Microlite) will begin supporting
OBDR based crash recovery under OpenServer.

Because OBDR is CD-ROM based, the work that we've been doing with
it has been done in parallel with work on making CD-R/RW drives more
useful under these platforms.

We're happy to report that the following capabilities will all be available
in our new release...

 o Bootable backups made to OBDR tape drives.

 o CD-R/RW RecoverEDGE boot media to replace / supplement floppy media.
 o CD-R/RW backups.
 o CD-R/RW backups that are bootable into RecoverEDGE.

 o DVD-RAM RecoverEDGE boot media to replace / supplement floppy media.
 o DVD-RAM backups.
 o DVD-RAM backups that are bootable into RecoverEDGE.

At this point, a SCSI CD-R/RW drive or DVD-RAM drive is required for our
OpenServer and UnixWare products, although ATAPI or SCSI is acceptable
for our Linux products.

We HIGHLY recommend (but are not strictly limited to)
CD-R/RW drives that support Burn-Proof technology.

I've over-written my tape

You accidentally over-wrote a tape. You didn't write much, so the rest of the tape still has your data. How to get at it?

Generally: not easy. Tape drives are usually incapable of moving past a End Of Data (EOD) mark. No amount of clever dd skipping etc. will work - the tape drive itself is not going to move past that mark. However: it MAY be possible to do this by deliberately overwriting the tape again for long enough to reach the current EOD point and beyond, and then (ugh), kill power to the drive before it writes EOD again. You are then left with junk at the beginning of the tape, and maybe what you need beyond. Keep in mind that tape writes on multiple tracks, so you are going to lose more than you think - see Bill Vermillion's Tape Articles. Here's someone who says they were able to use the over-write method and also mentions the remote possibility of finding software from the tape manufacturer to help: https://www.linux.org.za/Lists-Archives/glug-9708/msg00015.html

I think I'd go to one of the data recovery firms that specialize in tape before I'd try this.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Tapes and Tape Drives

Inexpensive and informative Apple related e-books:

Take Control of Upgrading to El Capitan

iOS 10: A Take Control Crash Course

Take Control of High Sierra

Take Control of Pages

Take Control of Automating Your Mac

More Articles by © Tony Lawrence


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

As soon as an Analytical Engine exists, it will necessarily guide the future course of the science. Whenever any result is sought by its aid, the question will then arise — by what course of calculation can these results be arrived at by the machine in the shortest time? (Charles Babbage)

Linux posts

Troubleshooting posts

This post tagged:



Tape Drives

Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode