NAME

mt − magnetic tape interface and controls

DESCRIPTION

This entry describes the behavior of HP magnetic tape interfaces and controls, including DDS and QIC cartridge drives.  The files /dev/rmt/* refer to specific raw tape drives, and the behavior of each given unit is specified in the major and minor numbers of the device special file. 

The following naming conventions are recommended because they relate most of the mode flags to the device name:

/dev/rmt/(c # d) # [hml] {c}{n}{b}

or

/dev/rmt/(c # d) # qic [525|150|120] {n}{b}

In this format, c # d indicates the controller number (optionally specified by the system administrator), # is the device number, hml indicates the density (h (high) for 6250 bpi, m (medium) for 1600 bpi, and l (low) for 800 bpi), c indicates data compression, n indicates no rewind on close and b indicates Berkeley style.  For example, /dev/rmt/2mn is device lu 2, AT&T style at 1600 bpi with no rewind and no compression.  The selection of controller and unit numbers is system dependent, and is discussed in the appropriate system administrator’s manual. 

For S800 QIC devices, qic (without a format number, i.e. default format) indicates the best capacity format for the drive and currently loaded medium, qic525 for QIC-525/320 format, qic150 for QIC-150 format, and qic120 for QIC-120 format. 

Accessing a QIC device through a /dev/rmt/(c # d) # [hml] device file is equivalent to /dev/rmt/(c # d) # qic in that a default format will be selected. 

The operation of a tape drive is controlled by mode flags, which are usually encoded as bits in the minor number of the device special file. 

no-rewind Unless this mode is requested, the tape is automatically rewound upon close.  When a rewind on close is not desired, the n flag should be used in the device name. 

style When this mode is requested, the tape drive behaves as on Berkeley systems; when not requested, the drive behaves as on AT&T UNIX operating systems.  The details are described below.  The ioctl(2) operations described below work in both modes. The mt(1) tape movement utility requires that the Berkeley mode be specified.

density This may be used to select the density of the tape being written.  Values that may be selected include 6250, 1600, and 800 bpi, depending on the capabilities of the specific tape drive.  This corresponds to the h, m and l flags in the recommended device name.  For DDS (digital audio tape) and QIC (quarter inch tape) format devices, density designations are not used. 

format This may be used to select the QIC format of the cartridge being written.  See DEPENDENCIES. 

compression On tape drives that support data compression, selecting the device file with c causes the data to be written or read in compressed mode. 

Refer to the system administrator manual for your computer for more specific details of how to select the modes for a given device. 

When opened for reading or writing, the tape is assumed to be positioned as desired. 

When a file opened for writing is closed, two consecutive EOF marks are written if, and only if, one or more writes to the file have occurred.  The tape is rewound unless the no-rewind mode has been specified, in which case the tape is positioned before the second EOF just written.  For QIC devices only one EOF mark is written and the tape is positioned after the EOF mark if the no-rewind mode has been specified. 

When a file open for reading only is closed and the no-rewind bit is not set, the tape is rewound.  If the no-rewind bit is set, the behavior depends on the style mode.  For AT&T-style devices, the tape is positioned after the EOF following the data just read.  For Berkeley-style devices, the tape is not repositioned in any way. 

Each read(2) or write(2) call reads or writes the next record on the tape. For writes, the record has the same length as the buffer given (within the limits of the hardware).

During a read, the record size is passed back as the number of bytes read, up to the buffer size specified.  The number of bytes ignored (for records longer than the buffer size specified) is available in the mt_resid field of the mtget structure via the MTIOCGET call of ioctl(2). The buffer and size might have implementation-dependent alignment restrictions.

Reading an EOF mark is returned as a successful zero-length read; that is, the data count returned is zero and the tape is positioned after the EOF, enabling the next read to return the next record. 

DDS format devices also support setmarks which are hierarchically superior to filemarks.  A setmark is used to delineate a group (set) of files.  Reading a setmark is also returned as a zero-length read.  The two can be distinguished by unique bits in the mt_gstat field. 

Spacing operations (back or forward space, setmark, file or record) leave the tape positioned past the object being spaced to in the direction of motion.  In other words, backspacing a file leaves the the tape positioned before the file mark; forward spacing a file leaves the tape positioned after the file mark.  This is consistent with all classical usage on tapes. 

Seeks on a magnetic tape device are ignored.  Instead, the ioctl(2) operations below can be used to position the tape and determine its status.

The header file <sys/mtio.h> has useful information for tape handling.  The following is included from <sys/mtio.h> and describes the possible tape operations:

/* mag tape I/O control requests */

#define  MTIOCTOP	_IOW(m,1,struct mtop)	/* do mag tape op */
#define  MTIOCGET	_IOR(m,2,struct mtget)	/* get tape status */

/* structure for MTIOCTOP - mag tape op request */

structmtop {

		short	mt_op;	/* operations defined below */
		daddr_t	mt_count;	/* how many of them */

};

/* operations */

#define MTWEOF	0	/* write filemark (end-of-file record) */
#define MTFSF	1	/* forward space file */
#define MTBSF	2	/* backward space file */
#define MTFSR	3	/* forward space record */
#define MTBSR	4	/* backward space record */
#define MTREW	5	/* rewind */
#define MTOFFL	6	/* rewind, put drive offline */
#define MTNOP	7	/* no-op, may set status */
#define MTEOD	8	/* DDS and QIC only. seek to end-of-data */
#define MTWSS	9	/* DDS only. write setmark(s) */
#define MTFSS	10	/* DDS only. space forward setmark(s)*/
#define MTBSS	11	/* DDS only. space backward setmark(s)*/

/* structure for MTIOCGET - mag tape get status command */

structmtget {

		long	mt_type;
		long	mt_resid;

/* The following two registers are device dependent */

		long	mt_dsreg1;
		long	mt_dsreg2;

/* The following is a device-independent status word */

		long	mt_gstat;
		long	mt_erreg;

Information for decoding the mt_type field can be found in <sys/mtio.h>.

EXAMPLES

Assume that fd is a valid file descriptor.  The first example writes two consecutive filemarks on the tape:

#include <sys/types.h>
#include <sys/mtio.h>

struct  mtop mtop;

mtop.mt_op = MTWEOF;
mtop.mt_count = 2;
ioctl(fd, MTIOCTOP, &mtop);

If fd is a valid file descriptor for an open DDS drive, the following example spaces forward to just past the next setmark:

#include <sys/types.h>
#include <sys/mtio.h>

struct  mtop mtop;

mtop.mt_op = MTFSS;
mtop.mt_count = 1;
ioctl(fd, MTIOCTOP, &mtop);

Now suppose that fd is a valid file descriptor for an opened tape device, and suppose further that it has just returned zero from a read(2) request. To verify that the tape has just read a filemark, the application could issue the following system call:

#include <sys/types.h>
#include <sys/mtio.h>

struct mtget mtget;

ioctl(fd, MTIOCGET, &mtget);
if ( GMT_EOF (mtget.mt_gstat)) {
/* code for filemark detection */
}
 

WARNINGS

It is impossible to write a program that leaves a tape positioned at the beginning of the tape on an AT&T-style device with the no-rewind bit set because closing the device file upon the program’s termination repositions the tape after the first EOF mark. 

An AT&T-style device file opened for writing to blank media may cause an error condition at close (due to attempting to space to the non-existent next EOF mark) unless a tape alteration operation has been performed. 

HP-UX silently enforces a tape record blocking factor (MAXPHYS) on large I/O requests.  For example, a user write request with a length of ten times MAXPHYS will actually reach the media as ten separate records.  A subsequent read (with ten times MAXPHYS as a length) will look like a single operation to the user, even though HP-UX has broken it up into ten separate read requests to the driver.  Such activity is normally transparent to the user unless:

• The user picks an arbitrary read length that is greater than MAXPHYS. 

• The user attempts to read a third-party tape containing records larger than MAXPHYS. 

Since the value for MAXPHYS is relatively large (usually >= 64K bytes), this is typically not a problem. 

Write operations on a QIC device can be initiated only at BOT or EOD.  No overwriting is allowed by positioning the tape in the middle of recorded data. 

The offline operation puts the QIC drive offline.  The cartridge is not ejected as done for DDS.  To put the drive back online, the cartridge has to be manually ejected and then reinserted. 

Sequential-Access devices that use the SCSI-1 I/O interface do not always report true media position. 

DEPENDENCIES

Series 300/400
QIC is not supported.

Series 800
The MTNOP operation does not set the device-independent status word. 

QIC devices do not always report media position accurately. 

If no QIC specific format is specified in the minor number, the best capacity format for the drive and currently loaded medium is used. 

The maximum I/O request for QIC devices is limited to 64K - 1 (65535) bytes. 

Efficient use of streaming tape drives with large internal buffers and immediate-reporting require the following end-of-tape procedures:

All writes near the EOT foil (which is not on the recording surface) complete without error if actually written to the tape. Once the tape drive determines that the foil has been passed, subsequent writes do not occur and an error message is returned. 

Since some applications require that a trailer be written for multiple tape operations, a user request for magnetic tape status that reflects the EOT condition signals the driver to drop all write barriers.  Caution must be exercised to keep the tape on the reel. 

When reading near the end-of-tape, the user is not informed of the EOT foil marker.  Instead, the typical double EOF marks or a pre-arranged trailer signals the logical end-of-tape. 

The EOT description above applies in the default case when immediate-reporting mode is allowed by a value encoded in the minor number.  When not permitted by the minor number, the EOT operation attempts to emulate compatibility-mode on other HP-UX machines.  In this mode, the write encountering the EOT foil returns an error with the tape automatically backing up over that record.  The read encountering the EOT foil returns an error. 

Since magnetic tape drives vary in EOT sensing due to differences in the physical placement of sensors, any application (such as multiple-tape cpio(1) backups) requiring that data be continued from the EOT area of one tape to another tape must be restricted.  Therefore, the tape drive type and mode should be identical for the creation and reading of the tapes. 

The following macros are defined in <sys/mtio.h> for decoding the generic status of the tape drive (returned in the mt_gstat field):

GMT_BOT(x)	/* At beginning of tape */
GMT_EOD(x)	/* DDS and QIC End-of-Data encountered */
GMT_EOF(x)	/* At an EOF mark */
GMT_EOT(x)	/* At end of tape */
GMT_DR_OPEN(x)	/* Drive door is open */
GMT_IM_REP_EN(x)	/* Immediate reporting mode enabled */
GMT_ONLINE(x)	/* Drive is on line */
GMT_SM(x)	/* setmark encountered */
GMT_WR_PROT(x)	/* Tape is write protected */
GMT_D_6250(x)	/* Density is 6520 bpi */
GMT_D_1600(x)	/* Density is 1600 bpi */
GMT_D_800(x)	/* Density is 800 bpi */
GMT_COMPRESS(x)	/* Data compression enabled */
GMT_QIC_FORMAT(x)	/* QIC format on tape */
GMT_QIC_MEDIUM(x)	/* QIC medium type*/

If GMT_IM_REP_EN(x) is true, the drive reports completion of each operation immediately after receiving it. 

AUTHOR

mt was developed by HP and the University of California, Berkeley. 

FILES

/dev/rmt/∗

SEE ALSO

dd(1), mt(1), ioctl(2), ct(7). 
 

Hewlett-Packard Company  —  HP-UX Release 9.0: August 1992