Tape Device Driver Notes

About this document

The following information is about fields that can be set during configuration of tape device drivers in SMIT.

BLOCK size (0=variable length)

Tape devices support multiple tape files. Tape files are the result of a command in which the device is opened, written to, and closed, such as the backup, cpio, tar, and dd commands. Because tapes allow large quantities of data to be written on a single tape, several backups, that is, tape files may be combined on one physical tape. Between each tape file is a tape file mark or file mark. These file marks are used by the device driver to indicate where one tape file ends and another begins.

 
                                B       E 
                     <-------   O       O   -------> 
                                T       T 
                __ ____________________________ _____________ 
       physical | \            |       |      \             |physical 
       beginning|  \           | tape  |       \            | end 
         of     |   \          | file  |        \           |  of 
        tape    |    \         | mark  |         \          | tape 
                |_____\________|_______|__________\_________| 

There is a distinction between the beginning of tape (BOT) side of a file mark and the end of tape (EOT) side of a file mark. If the head is on the BOT side of a file mark, the tctl fsf 1 command will only move the head to the EOT side of the same file mark.

With the 1/4" TAPE DRIVE, writing is sequential and can only take place at BOT or after blank tape has been detected. Only at BOT can the user write over data on the tape. If the user wishes to add data to a tape which has been written and then rewound, they should space forward file mark until an error () occurs. Only then can writing start again.

With an 8MM TAPE DRIVE, writing can only take place before blank tape, an EXTENDED file mark, or at BOT. Therefore, if several backups have been made on one tape, extended file marks were used, and if the user wishes to overwrite one of the backups, position the tape to the place to start writing and issue the following commands:

 
    tctl bsf 1 
    tctl eof 1 

The first command skips back to the BOT side of the same file mark. The second command rewrites the file mark. Writing is allowed before extended file marks. The erase head will erase data ahead of the write head, so that after writing the file mark there will be blank space. Only after this may the user start writing over data in the middle of the tape. All data beyond where the user is currently writing will be lost.

NOTE: A short file mark cannot be written over unless there is blank tape after the short file mark.

A rewrite in the middle of a tape can only be done if there is an extended file mark. SMIT can be used to change the type of file marks used.

With the 9-TRACK DRIVE, writing can take place anywhere on the tape, although overwriting of single blocks of data is not supported.

When data is written to tape, it is written in blocks. The blocks on a tape are separated by inter-record gaps. It is important to understand the structure of the written tape in order to understand the problems which can occur with changing block sizes.

In fixed block size mode all blocks on the tape are the same size. They are the size of the block size set in the device configuration. All read()s and write()s to the tape drive must be a multiple of the fixed block size.

In fixed block size mode, a read() will return as many blocks as needed to satisfy the read() request. If a file mark is encountered during the read, only the data up to the file mark will be returned.

In fixed block size mode, it is not possible for the tape drive to read a tape whose block size is not the same as the block size in the device configuration.

In variable block size (0) mode, the blocks written on the tape are the size of the read() and write() requests to the device driver. In this case, the actual block sizes on the tape can be changed using options of the backup commands:

 
    tar -b, cpio -C, backup -b 

In variable mode, read() requests greater than the size of the block on the tape will return only the data from the next block on the tape. It is this feature that allows tapes written in any block size, fixed or variable, to read with the dd command. For example, the output from the dd command may be piped to restore, tar, or cpio.

NOTE: The backup, tar, and cpio commands cannot read all tapes by using a large block size because they assume there is an error if they get a short read().

For example:

    dd ibs=128k obs=16k if=/dev/rmt# | ... 

The tape head is always positioned at an inter-record gap, file mark, or blank tape after reading or writing.

With the 8MM tape drive, the use of a fixed block size, which is not a multiple of 1K, is inefficient. The 8mm tape drive always writes internally in 1K blocks. It simulates the effect of variable block sizes. For example, using a fixed block size of 512 bytes (or using variable block size and writing 512 bytes at a time) wastes one half of the tape capacity and decreases the maximum transfer rate.

• Most tape drives, including non-UNIX and non-IBM, support both variable and fixed block sizes.
• With non-IBM UNIX, avoid block sizes of 64K (-C128) and greater because UNIX often internally divides larger reads and writes into manageable pieces (often 65535, 65534, or 65532 bytes) before doing the actual reads and writes. This means that reads and writes of 64K bytes are often broken up into a 65535-byte record and a 1-byte record. In fixed block mode, the write of 64K bytes will fail. The IBM AIX kernel does not break up read and write requests.

  NOTE: Be aware of this situation on other machines.

• If you need to read a tape written in an unknown block size, set the device configuration in SMIT to use variable size blocks, use the dd command with a large input block size, and pipe it to the restore, tar, or cpio command, as appropriate. For example:

 
    chdev -l rmt# -a block_size=0 
    dd if=/dev/rmt# ibs=128k obs=16k | tar -tvf- 

[ Doc Ref: 90605224414670     Publish Date: Oct. 16, 2000     4FAX Ref: 2208 ]