Tapes and Tape Drives

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

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:

http://aplawrence.com/cgi-bin/ta.pl?arg=109447

http://aplawrence.com/cgi-bin/ta.pl?arg=105776

http://aplawrence.com/cgi-bin/ta.pl?arg=109266

http://aplawrence.com/cgi-bin/ta.pl?arg=104978

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!

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
 

to

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 Exabytes' "Integrating a Tape Drive into a Linux System "

See Reading SCO tapes on Linux.

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: http://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.

---

© September 1998 Anthony Lawrence. All rights reserved.

If this page was useful to you, please click to help others find it:   Your +1's can help friends, contacts, and others on the web find the best stuff when they search.

Comments?

More Articles by Tony Lawrence - Find me on Google+

Site map | Disclaimer
"Using Tapes and tape drives" Copyright September 1998 Tony Lawrence

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.