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:
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
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.
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
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.
Pushing the eject button doesn't work.
First, check that no process is using the tape:
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.
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
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
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:
(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
This newsgroup post offers some other useful information. I was unable to find the original:
From: "D. Thomas Podnar" <email@example.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. ---------------------------------------- BACKGROUND - DAT and DDS TAPE TECHNOLOGY ---------------------------------------- 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 nil. 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. Compatibility. 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 devices... 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.
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.
More Articles by Tony Lawrence © 2013-08-14 Tony Lawrence
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)