ABSTRACT: <Tape> Device Driver Notes

 ABOUT THIS DOCUMENT

       These notes are intended as a supplement to the information
       contained in Info Explorer.  The reader should be familiar
       with the documentation available in Info Explorer before
       reading this document.  This document applies to AIX 3.1 and
       3.2 with the RISC System/6000.

  CONFIGURING THROUGH SMIT

       The following are notes about fields that can be set during
       configuration of <tape> device drivers in smit.

       "<BLOCK> <size> (0=variable length)"

       This field sets the <tape> <block> <size>.  The <block> <size> must be
       the same when a <tape> is read as it was when the <tape> was
       written.  With some commands, <tapes> written with ANY <block>
       <size> can be read if the <block> <size> is set to 0 (variable
       length) (see "<Block> <Sizes>" on page 3).

       "Use DEVICE BUFFERS during writes"

       When this field is set to "yes", the device will buffer data
       internally on writes.  This greatly improves performance,
       but in certain cases it may be undesirable since a "suc-
       cessful completion" indication is returned before the data
       is actually written to <tape>.

       "Use EXTENDED file marks"  (8mm only)

       Extended file marks take up much more space than short (or
       non-extended) file marks.  But extended file marks can be
       overwritten, allowing data which is not at the beginning of
       the <tape> to be overwritten (see "File Marks" on page 2).

       "Enable ECC"  (1/4" only)

       This field adds an Error Correction Code (ECC) to the data.
       THIS SHOULD ALWAYS BE SET TO OFF.  It has been disabled in
       later versions of AIX.

       "RETENSION on <tape> change or reset"  (1/4" only)

       If this field is set to "no", the <tape> will not be
       retentioned automatically when the <tape> is inserted.  Note
       that this will take effect only after the device is used.

  FILE MARKS

       <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>
                |_____\________|_______|__________\_________|

       Note that 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
       filemark, 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 you write over data on the <tape>.  If you
       wish to add data to a <tape> which has been written and then
       rewound, you should space forward file mark until an error
       () occurs.  Only then can you start writing again.

       With an 8MM <TAPE> DRIVE, writing can only take place before
       blank <tape>, an EXTENDED file mark, or at BOT.  Thus, if
       several backups have been made on one <tape>, extended file
       marks were used, and you wish to overwrite one of the
       backups, position the <tape> to the place you wish 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 you start writing over data in the middle of the
       <tape>.  (All data beyond where you are currently writing will
       be lost).  Note that you cannot write over a short file mark
       (unless there is blank <tape> after the short file mark).  You

       can only rewrite in the middle of a <tape> if there is an
       extended file mark.  You can use smit 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.

  <BLOCK> <SIZES>

       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> 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 (the output from the dd command may be
       piped to restore, tar, or cpio, for example.)  Note that
       backup, tar, and cpio cannot read all <tapes> by using a large
       <block> <size> because they assume there is an error if they get
       a short read().

         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>, but, for example, using a
       fixed <block> <size> of 512 bytes (or using variable <block> <size>
       and write()ing 512 bytes at a time) wastes one half of the
       <tape> capacity and decreases the maximum transfer rate.

  EXCHANGING DATA WITH NON-UNIX AND NON-IBM MACHINES

       o   Most <tape> drives (including non-UNIX and non-IBM)
           support both variable and fixed <block> <sizes>.

       o   With non-IBM UNIX, avoid <block> <sizes> of 64K (-C128) and
           greater, because UNIX often internally chops 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 mode, the write of 64K bytes
           will fail.)  The IBM AIX kernel does not break up read
           and write requests, but be aware of this situation on
           other machines.

       o   If you need to read a <tape> written in an unknown <block>
           <size>, set the device configuration in smit to use vari-
           able <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-


  SPECIAL NOTICES

       Please use this information with care.  IBM will not be
       responsible for damages of any kind resulting from its use.
       The use of this information is the sole responsibility of
       the customer and depends on the customer's ability to eval-
       uate and integrate this information into the customer's
       operational environment.