Making Tape-to-Tape Copies

Packey P. Velleca

Quarter Inch Cartridge (QIC) tapes have many formats, ranging, among others, from QIC-24 to QIC-525. These formats specify a standard for recording data on tape with a fixed block size, generally 512 bytes. QIC formats differs in this regard from 8mm or 9-track formats, which are variable record length (block size) recording devices. This article discusses some of the details involved in copying fixed block (specifically, QIC) tapes, and presents a program capable of copying one QIC tape to another.

Why a Tape-to-Tape Copy?

Tape copying is useful for several purposes. Many vendors deliver software on QIC tape, and making backups of these is a very good idea. If you use the vendor copy to load machines, eventually the tape will fail, and you will be forced to wait for the vendor to send another. Another use is in a software production environment, where engineering can cut one tape of a product, and another organization can use that tape as the master for generating multiple distribution copies.

A third use for tape copying is to convert the tape format or distribution medium. Vendor software is often supplied in a slow, low-density format, such as QIC-24 or QIC-150. If your tape drives support higher densities, you can make your working copy of the software on a high-density tape. (Typically, QIC-320 tapes load twice as fast as QIC-150 tapes!) Also, your vendor may supply software in one medium (e.g., DEC CompacTape TK-50), while you prefer to load your machines with another medium (e.g., QIC), perhaps to decrease load time. It is easy to use tape procedures to copy from one type of media to another.

A common alternative to tape-to-tape copying is to copy data from tape to another device, such as a large hard disk, and then copy the data from the drive to another tape. While a tape-disk-tape copy will do in a pinch, it does not make good use of your system resources. It is twice as slow as tape-to-tape copy (tape to disk, then disk to tape), and can require significant disk space. A tape-to-tape procedure minimizes time and resource usage. The only requirement is for a system with two or more tape drives.

Tape-to-Tape Copy Issues

With fixed block size devices, all tape operations are in multiples of the block size. A file that is smaller than the block size or a block size multiple must be padded out, usually with null characters. For example, to write a 300-byte file to a QIC-150 tape, you must pad the file to 512 bytes. File padding is normally transparent, however, as it is usually done by the application program, as, for example, tar(1), cpio(1) and dump(8). It is only with programs like dd(1) that you must be careful about padding when writing files directly to tape. Table 1 presents a list of commonly used formats and their capacities.

Padding is not an issue when you are writing files from one fixed block device to another, because you can assume the data on the source tape has been written correctly (i.e., padded if necessary). The files on the source tape can be of any format -- tar(1), cpio(1), dump(8) or dd(1) for example -- and copying from one tape to another is a simple matter of transferring bits from one device to another. The remaining concerns related to tape copying have to do with ensuring that the drives stream for best performance, specifying the read/write format, and determining the number of files on a tape.

Streaming on a tape drive signifies that the device is never waiting for data to read or write. Streaming optimizes device use and reduces waiting time. The buffering provided by dd(1) makes it easy to set up tape streaming when performing a tape-to-tape copy. By setting dd's bs argument to some large multiple of the device block size, you can make the drives stream. I have found that bs=10k (or more) will allow most QIC drives to stream.

In tape-to-tape copying you must read the source tape in some format, A, and write that data to a destination tape in some format, B, where A and B do not necessarily have to be the same. It is possible to copy a QIC-24 tape to a QIC-320 tape (assuming your tape drive can support QIC-320) to allow faster (about twice as fast) data transfer rates. Generally, though, tape-to-tape copy involves reading and writing in the same format, and this can simplify matters for the uninitiated. In this instance, the copy is only a matter of reading the source tape format -- a feature performed automatically by almost all tape drives.

Determining the destination tape write format is not necessarily so automatic, because the device assumes you know which format you want to write, and because it is possible to write many formats on many tape types.

You can determine the number of files on a tape automatically by successively reading files until an EOT marker or the last EOF marker is reached. In either case, the device will return a read-fail status.

Description of the Script

The ksh(1) script in Listing 1 (tape2tape) copies one QIC tape to another, with no operator intervention. The program assumes the platform is configured with at least two tape drives. The drives do not have to be the same device type -- one might be a QIC-320 drive, for example, and the other a TK-50.

When you execute the script, it will assert its default settings for input device, output device, number of files to copy, checksums, and block size, and prompt you to change them. When that is done, it will check the status of the tapes (e.g., ONLINE, WRITE PROTECT, etc.), rewind them, and begin the copy.

If you invoked the script with no arguments, then it assumes the number of files on the source tape is unknown and copies files until it encounters End Of Tape (EOT). At this point, if checksums are to be performed, it rewinds both tapes, and performs a file-for-file, tape-for-tape checksum comparison. Otherwise, it simply rewinds the tapes and terminates. If you know the number of files, you can specify the number on the command line as an option. You can also use this option to copy, say, only the first of many files on a tape.

The script automatically determines tape formats. It finds the source tape format via the device driver upon reading. It finds the destination tape format by making writes, at successively lower capacity formats, to the destination tape. The first successful write is the default write format.

The default device files for this script are /dev/nrmt0h and /dev/nrmt1h (if your system uses different device file names, then change them at line 38). dd(1) uses these arguments as input and output files. On most systems, the special file for the tape drive denotes the format of the tape operation. For example, with DEC Ultrix, /dev/rmt0h is QIC-320, rmt0m is QIC-150, rmt0l is QIC-120, and rmt0a is QIC-24. Consult your system manual for the file names for the supported formats of your tape drives. See Table 2 for other tape characteristics.

The default block size is 10k as denoted on line 306. dd(1) also uses this argument to specify input and output block size. As I noted earlier, 10k should work well if your device supports it. If not, try 8k instead. Just remember to keep the number large in order to keep the drives streaming.

If you invoke the program with the -c option, it will toggle its default checksum setting. For example, if the default checksum is TRUE, the -c will not perform checksums. The default checksum setting is configurable on line 45.

About the Author

Packey Velleca currently works with a group of administrators for a small system of real-time computers with UNIX-based operator workstations. He graduated from Florida Institute of Technology in Melbourne, FL, with a BSEE in 1988. He has published several articles in Sys Admin. He may be contacted as pvelleca%core1@kssib.ksc.nasa.gov.