Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!artcom0!pf
From: pf@artcom0.north.de (Peter Funk)
Newsgroups: comp.unix.internals
Subject: Notes on the behaviour of raw tape device drivers
Summary: Some notes on the portability of programs accessing tape drives.
Keywords: raw tape i/o, ANSI X3.27, blocking
Message-ID: <3090@artcom0.north.de>
Date: 7 Dec 90 14:48:27 GMT
Distribution: world,comp
Organization: ArtCom GmbH, Atelier f. Computergrafik, Bremen(FRG)
Lines: 87

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 ! <<