Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.20/text0017.txt

Internet Message Format | 1990-08-02 | 3.6 KB

From:  [e-mail] (Guy Harris)

>I am interested in finding out the current state of standards efforts
>in regards to tape drivers, specifically:
>
>Is there any standard ioctl interface to take advantage of the flexibility
>afforded by the SCSI interface?

There's a *de facto* semi-standard (as in "there are probably retrograde
systems that do it differently but no better, and are definitely systems
that don't do it at all"), namely the "ioctl"s provided by 4.xBSD.  They
don't "take advantage of the flexibility afforded by the SCSI interface"
in the sense that they let you do stuff that works only on SCSI tapes;
the "ioctl"s include one to perform "special functions", including
spacing forwards and backwards by files and by blocks, rewinding,
rewind-and-unload, etc., but you can do those on non-SCSI tape drives as
well.

>I have heard rumors that AT&T has come up with a proposal (or perhaps a
>de-facto standard in SVR4), but don't have any details.  Can anyone
>supply me with some?

All I know of is that AT&T provides, in the "Berkeley compatibility"
package, the 4.xBSD (or maybe SunOS 4.x, derived from 4.xBSD) "mt"
command, and it probably uses the BSD "ioctl"s.  They provide
<sys/mtio.h> (the include file that defines those "ioctl"s, and the
commands they perform and data structures they use), but only as part of
the compatibility package, not as an official part of S5R4.  In fact,
the S5R4 "BSD/XENIX(R) Compatibility Guide" says, about the "mt"
command:

    Both rely in a set of "ioctl"s that are not present in default
    UNIX System V.  However, users with new or enhanced device
    drivers may take advantage of this command.

Which means that, if you want to provide them with your S5 port, you can
do so; if you're going to provide "ioctl"s of that sort, it's probably
best to provide the BSD ones or ones based on them.

>Is there any standard action for what a tape driver should do with
>internal flags (End-Of-Media, Filemark, etc.) when it receives an ioctl
>call (like, clear the "DataWritten" flag so filemark writing won't be
>performed after an ioctl)?

No official one; the drivers I know of tend to clear the "data written"
flag after repositioning the tape.

>Is there any standard defined for what drivers should do with the
>bp->b_blkno?  Early AT&T drivers (the Kennedy tape drive?) would
>support block device IO to tapes, and would space the requested number
>of 512-byte blocks if the b_blkno didn't match the driver's idea of
>where it was.  So what happens with, say, 5K blocks on a 1/2" tape
>reel?  Or should the driver just ignore the bp->b_blkno field
>altogether?

Some drivers use it, some ignore it.  I wouldn't go out of my way to pay
attention to it; it makes the driver more complicated and, given the
problem you note, and the fact that most of the mag tape use I'm
familiar with involves programs that don't seek around the tape, and the
fact that seeking on mag tapes is generally rather slow, I doubt it
actually makes life any better if the driver *does* try to pretend that
"lseek()" works on a mag tape.

Another disadvantage of the block device is that it has to pick some
arbitrary block size; said block size may not match the block size on
the tape (unless you're talking tapes like QIC tapes with a standard
block size), and may also be smaller than you'd like (512-byte blocks,
which are the default, at least in most non-4.[23]BSD systems, are
rather silly on 1/2" tapes, for instance).

>These questions are prompted by the infamous exabyte tape drive.

The BSD "ioctl"s long antedate Exabytes; they apply to all tapes, and
make life nicer on all tapes.

Volume-Number: Volume 20, Number 17