QIC cartridge tape questions

[Jeremy G Harris]

In article <1849 at hsi86.hsi.UUCP> stevens at hsi.UUCP (Richard Stevens) writes:
[..]
>I'm using a QIC-150 cartridge tape drive (SCSI interface) on a
>Data General AViiON, running DG/UX 4.30.
[..]
>What are the differences between these cartridge tape drives and
>"real" mag tapes ?  I'm aware of the limitation of writing 512-byte
>physical blocks.  That's fine -- everything I plan to write to the
>tape will be multiples of 512.  Is this the only difference ?

Not all tape drives can space backwards.

>Can I read and write EOF markers just like normal tapes ?

Yes.

>Do they use a double EOF to mark the logical EOT ?

Not necessarily.  If they cannot backspace then it becomes difficult
for the driver to do this and still deal reasonably with Unix file
semantics (which I interpret for tapes as meaning "write a filemark
upon close").
  A drive which can backspace could do the traditional (half-inch
magtape) "write two filemarks, backspace over one" trick; however,
when you transported that tape to a second drive which can't, you
wouldn't then be able to append further tape files without leaving
the double filemark still there.  So, how should one interpret a
double filemark, found on a QIC of unknown parentage?  As EOT or
as a zero-length file?

  Now, on QIC, the device of two EOF marks meaning (logical) EOT is
not required, since the drive forces blank tape after the end of data
and can detect this and return "End Of Data".

[ It does this by having a separate full-width erase head which is
  active during writes on track zero, and only permitting writing
  to start at the logical BOT.
]

  Given this, here's what drivers I have written do:

On writing, at close of file write one filemark.  Do rewind, retension
or nothing as appropriate.

On reading, when meeting a filemark, if there is remaining data, return
it and mark the tape drive status as "EOF read", else return zero data.
On a read at "EOF read" return zero data (Unix EOF indication).
Treat the first attempt to read an "End Of Data" condition as a filemark,
any further ones as a logged error.

This, I think (and if I've remembered it all correctly), brings you
maximum compatibility.



>
>The problems I'm having are with *multiple* files on a single tape.
>(Multiple tape files, not multiple Unix files.)
>
>For example, I rewind the tape, then write some records to the
>tape using tar.  I can read the tape using tar without any problems.
>But, if I rewind the tape, forward space one file (no-rewind device,
>of course) and then try to read the next file (expecting to hit the
>second EOF that should have been written when tar closed the device),
>I get a read error.  This implies that
>	(1) the driver didn't write two EOFs when tar closed the device;

Yup.

>	(2) cartridge tapes don't use double EOFs to delineate the
>	    logical EOT;

Yup.

>	(3) the driver doesn't handle the reading of two consecutive
>	    EOFs correctly.

I interpret this as: the driver doesn't do the "first EOD needs to be
translated for EOF for magtape back-compatibilty" kludge given above.


>
>As another test I rewind the tape and write some records to it using
>tar again.  When the tape is rewound I forward space one file, then
>use mt to write a single EOF.  This generates an "Invalid argument"
>error from the mt command.  This implies that
>	(1) you can't write an EOF after another EOF (i.e., you can't
>	    write a double EOF on the tape);
>	(2) the driver is really broken.

Worse.   You can't append to a tape unless you're at End-Of-Data.  The
trouble is that your drive doesn't know it's there yet since you haven't
tried to read it yet and it's too dumb to read ahead and.....
You get the picture.


In summary, the driver needs that EOD/EOF hack to un-break it.

Hope this helps.
-- 
Jeremy Harris			jgh at root.co.uk			+44 71 315 6600