NAME

mt − magnetic tape interface and controls

DESCRIPTION

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

The following naming convention is recommended for tape devices because it connects most of the mode flags with the device name:

/dev/{r}mt/(c#d)#[hml]{c}{n}

In this format, r indicates a raw device, 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, and n indicates no rewind on close.  For example, /dev/rmt/2mn is raw device 2 at 1600 bpi with no rewind and no compression.  Blocked magnetic tapes are used only for special situations and are supported only in some implementations.  See DEPENDENCIES below for details.  The selection of controller and unit numbers is system dependent, and is discussed in the appropriate system administrator’s manual. 

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 on raw tapes only. 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.  Within DDS Format devices (digital audio tape), density designations are not used. 

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. 

The special files associated with a raw tape interface are named rmt/∗.  Unless otherwise stated, the following discussion refers to raw magnetic tapes. 

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. 

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 raw 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 */

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

structmtop {

};

/* operations */

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

structmtget {

/* The following two registers are device dependent */

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

/* The following are used only when block devices are supported */

};

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

The preferred method for obtaining tape status is via the mt_gstat field.  Information for decoding the mt_gstat field is in <sys/mtio.h>.  mt_dsreg1, mt_dsreg2, and mt_erreg are useful only for HP-IB 9-track tape devices.  mt_gstat is in part a generic replacement for these registers. 

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

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:

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

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

For mag tape operations only the least significant 16 bits of mt_count are valid for DDS type devices when using MTWEOF, forward and backward record, file, and setmark commands. 

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

DEPENDENCIES

Series 300/400 and 700
Block magnetic tape is not supported.

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

The files /dev/mt/∗ refer to block magnetic tapes.  They should be used only for system installation or for treating a previously written magnetic tape as a read-only block file system. 

A read-only block tape should be created with dd(1) using raw mode and a record size of 512 or 1024 bytes. (The default record size is 512 bytes.) The driver requires exactly 512-byte records on the physical tape, or exactly 1024-byte records if hex 0x8000 is OR’ed into the minor number.  The 1024-byte option is intended for use with HP INSTALL/SUPPORT type file systems. 

Although the size of records on a block tape is always 512 (or 1024) bytes, the block I/O system deals with block sizes as a multiple of DEV_BSIZE (defined in <sys/param.h>), with the tape driver making the translation.  For this reason, if a user writes 512 bytes (for example) in block mode, the block I/O system attempts to read from the block tape prior to incorporating the new data and writing it to the tape.  Since reading a blank tape or a tape of unknown format terminates in an error, it is advised that dd(1) be used to create the tape as described above, and that block magnetic tape be used only for seeking and reading. Alternatively, always write a byte count that is a multiple of BLKDEV_IOSIZE (defined in <sys/param.h>) bytes to avoid the hazards of an erroneous prior block read. 

A tape treated as a block-special device consists of several 512-byte (or 1024-byte) records terminated by an EOF. 

The system enables a previously written block tape to be treated as an ordinary file, except that writing in the middle of a file truncates the file at that point.  Seeks have their usual meaning and it is possible to read or write a byte at a time. 

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

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/mt/∗
/dev/rmt/∗

SEE ALSO

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

Hewlett-Packard Company  —  HP-UX Release 8.05: June 1991