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.
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
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".
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".
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
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:
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
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
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.
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
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
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
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.
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.