|
|
HP-UX Reference Volume 5 of 5 > mmt(7) |
|
NAMEmt — magnetic tape interface and controls for stape, tape1 and tape2 DESCRIPTIONThis entry describes the behavior of HP magnetic tape interfaces and controls, including reel-to-reel, DDS, QIC, 8mm, and 3480 tape 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. Naming ConventionsThere are two naming conventions for device special files. The standard (preferred) convention is used on systems that support long file names. An alternate convention is provided for systems limited to short file names. The following standard convention is recommended because it allows for all possible configuration options in the device name and is used by mksf(1M) and insf(1M): /dev/rmt/c#t#d#[o][z][e][p][s[#]][w]density[C[#]][n][b] The following alternate naming convention is provided to support systems in which the /dev/rmt directory requires short file names. These device special file names are less descriptive, but guarantee unique device naming and are used by mksf(1M) and insf(1M) where required. /dev/rmt/c#t#d#[f#|i#][n][b] For each tape device present, eight device files are automatically created when the system is initialized. Four of these device files utilize either the standard (long file name) or alternate (short file name) naming conventions. When the standard naming convention is being utilized, these four files contain the density specification "BEST". When the alternate naming convention is being utilized, these four files contain the density specification "f0". There are four such files because each of the four different permutations of the "n" and "b" options (see below) is available. The remaining four files automatically created when the system is initialized utilize the pre-HP-UX 10.0 device file naming convention. This includes an arbitrary number to distinguish this tape device from others in the system, followed by the letter m. There are four such files because each of the four different permutations of the n and b options (see below) is available. These files are created as a usability feature for pre-HP-UX 10.0 users who do not wish to acquire familiarity with the standard or alternate naming conventions. Each of the automatically created four device files which utilize the standard or alternate naming conventions is linked to a device file which utilizes the pre-HP-UX 10.0 naming convention. Thus, the device files which utilize the pre-HP-UX 10.0 naming convention provide the same functionality as the device files which contain the density specification BEST (standard naming convention) or f0 (alternate naming convention). OptionsThe options described here are common to all tape drivers. The c#t#d# notation in the device special file name derives from ioscan output and is described on the manpages for ioscan(1M) and intro(7). Options unique to stape, tape1, and tape2, are described later in this manpage, in the DEPENDENCIES section.
Sample Tape Device Special File NamesFor a QIC150 device at SCSI address 3, card instance 2, with default block size, buffered mode, and AT&T-style with rewind on close, the standard device special file name is /dev/rmt/c2t3d0QIC150. For a device at card instance 1, target 2, LUN 3, with exhaustive mode enabled (see DEPENDENCIES), fixed block size of 512 bytes, DDS1 density with compression, AT&T-style with no rewind on close, the standard device file special name is /dev/rmt/c1t2d3es512DDS1Cn. For a system requiring short file names, the same device special file would be named /dev/rmt/c1t2d3i<#>n, where <#> is an index value selected by the tape driver. Use the lssf(1M) command to determine which configuration options are actually used with any device file. The naming convention defined above should indicate the options used, but device files may be created with any user defined name. Tape Behavioral CharacteristicsWhen 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 (End of File) 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 (unless already at BOT or Filemark). 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. Since the minimum read length on a tape device is a complete record (to the next record mark), 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). Current restrictions require tape device application programs to use 2-byte alignment for buffer locations and I/O sizes. To allow for more stringent future restrictions (4-byte aligned, etc.) and to maximize performance, page alignment is suggested. For example, if the target buffer is contained within a structure, care must be taken that structure elements before the buffer allow the target buffer to begin on an even address. If need be, placing a filler integer before the target buffer will insure its location on a 4-byte boundary. The ascending hierarchy of tape marks is defined as follows: record mark, filemark (EOF), setmark and EOD (End of Data). Not all devices support all types of tape marks but the positioning within the hierarchy holds true. Each type of mark is typically used to contain one or more of the lesser marks. When spacing over a number of a particular type of tape mark, hierarchically superior marks (except EOD) do not terminate tape motion and are included in the count. For instance, MTFSR can be used to pass over record marks and filemarks. 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 devices and the 8mm 8505 device also support setmarks , which are used to delineate a group (set) of files. For the 8mm 8505 setmarks are only supported when the density is set to 8500 plus compression. Reading a setmark is also returned as a zero-length read. Filemarks, setmarks and EOD can be distinguished by unique bits in the mt_gstat field. Spacing operations (back or forward space, setmark, file or record) position past the object being spaced to in the direction of motion. For example, back-spacing a file leaves the tape positioned before the file mark; forward-spacing a file leaves the tape positioned after the file mark. This is consistent with standard tape usage. For QIC devices, spacing operations can take a very long time. In the worst case, a space command could take as much as 2 hours! While this command is in progress, the device is not accessible for any other commands. lseek(2) type 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 command */ struct mtop { 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 and put the drive offline (may eject) */ #define MTNOP 7 /* no operation, may set status */ #define MTEOD 8 /* DDS, QIC and 8MM only - seek to end-of-data */ #define MTWSS 9 /* DDS and 8MM only - write setmark(s) */ #define MTFSS 10 /* DDS and 8MM only - space forward setmark(s) */ #define MTBSS 11 /* DDS and 8MM only - space backward setmark(s) */ /* structure for MTIOCGET - mag tape get status command */ struct mtget { long mt_type; /* type of magtape device */ long mt_resid; /* residual count */ /* The following two registers are device dependent */ long mt_dsreg1; /* status register (msb) */ long mt_dsreg2; /* status register (lsb) */ /* The following are device-independent status words */ long mt_gstat; /* generic status */ long mt_erreg; /* error register */ daddr_t mt_fileno; /* No longer used - always set to -1 */ daddr_t mt_blkno; /* No longer used - always set to -1 */ Information for decoding the mt_type field can be found in <sys/mtio.h>. Other Tape Status CharacteristicsEfficient use of streaming tape drives with large internal buffers and immediate-reporting require the following end-of-tape procedures:
When immediate-reporting is enabled, the tape1 and tape2 drivers will drop out of immediate mode and flush the device buffer with every write filemark or write setmark. The stape driver will flush the device buffers when a write filemark or write setmark command is given with the count set to zero. When immediate-reporting is disabled, the write encountering LEOT returns an error with the tape driver automatically backing up over that record. When reading near the end-of-tape, the user is not informed of LEOT. Instead, the typical double EOF marks or a pre-arranged data pattern signals the logical end-of-tape. 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 status field mt_gstat returned from MTIOCGET. For each macro, the input parameter <x> is the mt_gstat field.
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. The blocking function is transparent to the user during writes. It is also transparent during reads unless:
Since the value for MAXPHYS is relatively large (usually >= 256K bytes), this is typically not a problem. The MTNOP operation does not set the device-independent status word. 3480 stacker devices are supported only in auto (that is, sequential-access) mode. To advance to the next tape in the stack, an MTIOCTOP control request specifying an MTOFFL operation should be issued. An MTIOCGET control request should then be issued to determine whether or not the stacker has been successfully advanced. Failure on the MTIOCGET operation (or an offline status) indicates that no more tapes are available in the stacker, the stacker has been ejected, and user intervention is required to load a new stack. EXAMPLESAssuming that fd is a valid file descriptor, the following 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); Given that fd is a valid file descriptor for an opened tape device, and that it has just returned 0 from a read(2) request. The following system call verifies that the tape has just read a filemark: #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 */ } WARNINGSDensity specifications BEST (standard naming convention) or f0 (alternate naming convention) activate data compression on tape devices which support compression. This is also true for the files using the pre-HP-UX 10.0 naming convention which are linked to these files (see "Naming Conventions" above). This means that a tape written using one of the eight device files (which are automatically created when the system is initialized) on a tape device which supports data compression, will contain compressed data. This tape cannot be successfully read on a tape device which does not support compressed data. For example, a tape written (using one of the eight automatically created device files) on a newer DDS device which supports data compression cannot be read on an older DDS device which does not support data compression. To accomplish data interchange between devices in a case such as this, a new device file must be manually created using the mksf(1M) command. In the above example, the options specified to mksf(1M) should include a density option with an argument of DDS1, and must not include a compression option. Use the mksf(1M) command instead of the mknod(1M) command to create tape device files. As of the 10.0 release, there are more configuration options than will fit in the device file's minor number. Prior to the 10.0 release, it was possible to select configuration options by directly setting the bits in the device special file's minor number using mknod(1M). As of the 10.0 release, a base set of configuration options are contained in the minor number. Extended configuration options are stored in a table of configuration properties. The minor number may contain an index into the property table, which is maintained by the tape driver and is not directly visible to the user. The mksf(1M) command sets the minor number and modifies the property table as needed based on mnemonic parameters passed into the command. If your device configuration requirements are limited to the base set of options, you need not be concerned with the property table. The base configuration options are as follows:
All other configuration options are extended options that result in use of the property table. It is recommended that all tape device files be put in the /dev/rmt directory. All tape device files using extended configuration options must be put in the /dev/rmt directory. This is required for proper maintenance of the property table. Device files using a extended configuration options located outside the /dev/rmt directory may not provide consistent behavior across system reboots. Use the rmsf(1M) command to clean up unused device files. Otherwise, the property table may overflow and cause the mksf(1M) command to fail. Density codes listed in <sys/mtio.h> have device-dependent behaviors. See the hardware manual for your tape device to find which densities are valid. For some devices, these values may be referred to as formats instead of densities. Use of unbuffered mode can reduce performance and increase media wear. Reads and writes from/to older (fixed block) devices such as QIC150 must occur at exact multiples of the supported block size. Write operations on a QIC device can be initiated only at BOT or EOD. QIC devices will not allow writes with the tape positioned in the middle of recorded data. The offline operation puts the QIC drive offline. The cartridge is not ejected as is 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 I/O interface may not always report true media position. On a 3480 device with data compression enabled, writing of a single record that cannot be compressed to less than 102,400 bytes is not supported. Note that using the 8200 format on 8500-style 8mm devices will significantly reduce tape capacity, and that only the 8500c-density setting provides support for setmarks. The maximum I/O request for 8mm devices is limited to 240KB. DEPENDENCIESDriver-Specific Options for stape (major number 205)The following options may be used in creating device special files for tape drives that access the stape driver:
Driver Specific Options for tape1 and tape2 (major number 212)The following options may be used in creating device special files for tape drives that access the tape1 and tape2 drivers:
FILES
|
|