NAME

gt − Generic magnetic Tape interface

SYNOPSIS

Configuration file entry:
tapemt1at hs0 drive 5 tapemt1at is0 drive 5

DESCRIPTION

The gt(7) driver is the generic driver for tapes.  The gt(7) driver contains the tape specific components, and communicates with the interface module, which contains the interface specific code.  Currently the gt driver interfaces with the hs interface module which supports SCSI tape drives configured on the HVME SCSI Adaptor, and the is interface module which supports SCSI tape drives on the Integral SCSI/Ethernet Daughtercard (ISE). 

Only one process is allowed to have the tape drive open at a time.  EBUSY will be returned if you attempt to open a drive that is being used by someone else. 

End of Tape

The last write operation before end-of-tape is detected will either return less than the requested number of bytes or a 0, indicating no bytes were written.  Any subsequent write will return ENOSPC, and the tape position will not change. 

When using the fsf command with the nonrewinding device, attempts to space too many files forward will return an ENXIO.  The tape head will be positioned past the last filemark it crossed. 

FileMarks

Reading a filemark returns a zero length read.  Any further reads return ENXIO and the tape postion does not change. 

If the device is a nonrewinding one, was opened read-only (O_RDONLY), and neither a filemark nor double filemark has been detected, and the last tape operation was not a tape ioctl(), the tape is advanced to just after the next filemark. 

Drive Technology Differences

The gt(7) driver supports multiple technologies of tape drives.  Operation of some of the functions listed below differs based upon the drive type being used. 

1/4 inch cartridge drives support a special tape position called ’End Of valid Data’ (EOD).  The drive knows where the last write operation completed and calls this EOD.  Subsequent write operations can only be written at the Beginning of Tape (BOT) or at EOD.  Thus it is not possible, for example, to read tape and then write at the current position with 1/4 inch cartridge tapes. 

Other drives supported by the gt(7) driver do not have this limitation. 

End of Volume Marks

On 1/4 inch cartridge tapes, when the gt(7) device has been written to, a filemark will automatically be written to the tape at the End Of valid Data (EOD) when a close(2) is performed.  If the device is a rewinding device, another filemark will be written to signify End Of Volume (EOV), and then the tape will be rewound to Beginning Of Tape (BOT).  If the device is a nonrewinding one, the tape head will be left where the filemark signifying EOD was written.  To get the EOV filemark written on a nonrewinding device, the user must use the mt(7) ioctl MTOFFL.  This insures that there will be two filemarks signifying EOD at the EOV.  It follows that writing the last volume of a multiple file archive using the rewinding device will also ensure that the EOV mark is written. 

On other types of drives, when the the gt(7) device has been written to, two filemarks will automatically be written to the tape at the current position signifying EOV when the next operation will reposition the tape, (such as rewind or backspace or close).  On a close to the non-rewinding device, the drive is then backspaced over one of them. 

If the tape was not written to, and no filemark is needed, the tape head will be left where the last command left it. 

Write Append Operations

If the user would like to write to tape, and then back space, read some data, and then return to the last written location and continue writing, the new mt(7) ioctl, MTWIND, has been added for 1/4 inch cartridge drives.  This command can be used to position the tape head at EOD, so that you can write append.  NOTE: Using this command will invalidate the driver’s internal file and block counters.  The way to use this command without invalidating the drivers counters is to reposition the tape with the proper combinations of fsf and fsr, so that the tape is at the valid EOD, and then issue the MTWIND ioctl.  This allows you to write append. 

The MTWIND ioctl is not valid on other drive types. 

Tape Head Position When Backspacing

Some 1/4 inch cartridge tape drives do not support the back space command.  The gt driver is aware of this limitation and will perform the requested operation by rewinding, and then spacing forwards to the appropriate location.  The tape head will stop on the end of media side of the appropriate filemark, not the beginning of media as do drives with the backspace command.  A "forward space file" command will leave the tape head at the End Of Media (EOM) side of the appropriate filemark.  When the tape head is at the beginning of a file, it is located on the EOM side of the previous filemark.  If the tape head is located at the beginning of a file, then a single backspace file will put the tape head at the beginning of the previous file.  If the tape is in the middle of a file, so that there is data between the tape head and the previous filemark, then a single backspace file will put the tape head at the beginning of the current file.  Here are some examples:
 

Variable length record support

Some tape drives operate only with fixed physical block sizes on the tape.  For example the 1/4 inch cartridge tapes all use a physical block size of 512 bytes.  When using the raw device, the gt(7) driver will handle the blocking/de-blocking based upon the byte count specified in the user’s read or write request.  Assuming there is sufficient data on the tape, a read will always be satisfied to the size requested, regardless of the records size used when the data was written.  For example, if 1/4 inch cartridge tape was written using four writes of 256 bytes each, all of the data written can be read with a single read of 1024 bytes (or two reads of 512 bytes, etc).  The gt(7) driver provides no logical record separation. 

The other type of tape drive utilizes variable-length physical block sizes.  Examples of this are the 9-track 1/2 inch tape drives such as the Model 6750 supported by the gt(7) driver.  Each user write request is output to the tape as one physical block.  Each read request will input one physical block from the tape.  If the byte count on the read request is less than the size of the block, the remaining data is lost.  If the byte count is greater than the size of the block, only the physical record size is copied into the buffer and that size is returned to the calling program on the read. 

The Model 6150 Exabyte-8200 drive can operate in either fixed or variable block mode.   By default, it operates in fixed-block mode with a block size of 1024 bytes.  However, by issuing a mt(1) settype command to set the drive type to exabyte8200v the drive will operate in the variable-block-size mode.  The default for this drive can be altered by editing the usr/src/uts/machine/io/scsi_data.c configuration file supplied with the operating system.  By changing the type for the ’EXABYTE EXB-8200’  entry in the scsi_iq_data[] table from SCSI_EXB8200 to SCSI_EXB8200_VAR and relinking the kernel, the system will be initialized each time with the Exabyte operating as a variable-block-length device. 

Device registers accessible through mt(1) stat command

The two "device registers" that are accessible by using the mt(1) stat command or the mt(7) ioctl command are the "drive status" and "error" register.  These registers are not real hardware registers, just a means of transferring information about the drive to the user.  The error register will contain the value of the last error that occurred.  This error will remain in the register until another error occurs, so that the user can check to see what the last error was.  The value in the error register will be one of the IMERR errors which can be found in the im.h header file.  By using #define IM_ERRORS and including this header file, an application can check this error number, and use it to index into the im_errors array which contains the strings explaining the error.  The "drive status" register is composed of bits whose on/off value tells you detailed information about the drive.  The bits’ values are defined in the gt.h header file.  By using "#define GT_ERRORS" and including this header file, an application can find out information about the drive.  The GT_PRINT_DSREG macro in <sys/gt.h> can be used to print out the strings associated with the bits that are on in the ds register. 

Controller and drive model information accessible through mt(1) stat command

The gt(7) driver will return a value for both the type of controller, and the type of drive, when using the mt(1) "stat" command or the mt(7) MTIOCGET ioctl command.  Previous tape drivers would just return the type of controller.  For applications desiring to access this information using the MTIOCGET ioctl, the controller type is stored in the low byte of the mt_type field, and the drive model is stored in the high byte.  The MT_CTLR_MASK and MT_DRIVE_MASK defines in <sys/mtio.h> can be used to extract these values.  The controller value will match the MT_ISGT, and the drive model (shifted right one byte) will match one of the model numbers in <sys/mtio.h>. 

TAPE MODELS CURRENTLY SUPPORTED

DRIVE SPECIFIC FEATURES

SEE ALSO

gd(7), hsa(7), ise(7), mt(1), mt(7)
 

CX/UX Administrator’s Reference