pf@artcom0.north.de (Peter Funk) (12/07/90)
In some applications fields it is necessary for application-programs
to have some very specific kind of control on tape devices. This
applies not only to the well known old fashioned 9-track reel tapes
but also to modern devices like the 8 mm EXABYTE.
One of great advantages of UNIX (abstraction from physical devices
and modelling data as an unblocked stream of bytes) presents here some
serious difficulties to application programs, which either must be able
to write a tape using specific physical record lengths or must be able
to detect the physical record lengths of a given tape.
For example ANSI X3.27 specifies, that a tape must start with a sequence
of several blocks of 80 bytes each. (Remember : punchcards ! ;-)
A typical ANSI X3.27 tape may have the following _physical_ format:
7 records of 80 bytes
<filemark>
2192 records of 16384 bytes
<filemark>
6 records of 80 bytes
<filemark> <filemark> ; 2 filemarks mark the logical end of tape.
Please note: Not all records a the same tapefile must have the same
physical record size (as it is in this example) !
Since magnetic tapes are yet today a "quasi industrial standard" medium
for the exchange a large data, the question
"How should raw tape device drivers work ?"
should be of interest to most people using UNIX in an industrial
production environment. Since it in general bad, as we say in it
german if each vendor will 'cook his own soup', I would like to
discuss this subject.
As a start point for the discussion I point out the semantic, I've
implemented for our applications and in our tape device drivers:
1. Behaviour of 'write' :
Each 'write (rawtape, &buffer, recordsize);' will write
exactly 1 physical tape record of 'recordsize' bytes.
(Note that this may bring up some serious problems to networking
installations, which may split 1 'write'-Request from an application
program into several 'write'-Requests to the device driver on a
remote machine. At the moment, our customers are therfore unable to
use the tape unit across XENIX-NET. Since they are satisfied
with 'rlogin', this is no problem for me at the moment ;-)
2. Behaviour of 'read' :
Consider :
#define BIGBUFSIZE 65356
int readed;
readed = read (rawtape, &bigbuffer, BIGBUFSIZE);
will read exactly one physical record and return its size. So
the application program may determine the physical recordsize.
If the readed record doesn't fit into the buffer, the driver will
signal an error (I've used 'EOI'). If a filemark (which may be
considered as physical tape record of 0 bytes) is discovered
during the read, 'readed' gets 0.
Some drivers I've seen, will continue to return 0 on subsequent
reads, unless the device is closed and reopenend. This behaviour
may be reasonanble (since a filemark may be considered as some kind
of EOF-condition), but this has the disadvantage, that the
application program may lose control over the device (see 'lockf'),
when it is required to close the device. So I've implemented read
in a way, that subsequent reads will continue to read records behind
the filemark.
3. Behaviour of 'close' :
When writing to tape, 'close' writes 2 filemarks and repositions the
between the 2 filemarks, so that a subsequent open and further
writes will overwrite the second filemark. This behaviour guarantees,
that the tape is always properly terminated with 2 filemarks (the
convention for logical End-Of-Tape)
4. Behaviour of 'ioctl' :
The most beautiful solution would be, to avoid the use of ioctl
in application-programs at all. But there are some tape specific
functions (rewind, read backwards until last filemark, skip until EOT...)
which are sometimes nevertheless needed.
Of course there is no standard in sight, also nearly all
tape drivers, I've seen, implement a very similar functionality.
Important to note : To avoid the use of a 'rewind'-ioctl, several
vendors have implemented 'auto rewind on close' devices, which will
be distinguished by here its device number from the standard
tape device.
--
Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1
Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm)
>> PLEASE Don't send BIG mails (oversea) ! I've to pay for it : ~ $0.3/kB
Don't use the path of this news article for replies.
The address 'pf@artcom0.north.de' will work. Thank You ! <<