stevens@hsi.UUCP (Richard Stevens) (07/24/90)
Although I've used "real" mag tapes under Unix for years, I'm new to
the cartridge tape world and have a few questions (which I haven't
found answers to in any of the manuals that I have).
I'm using a QIC-150 cartridge tape drive (SCSI interface) on a
Data General AViiON, running DG/UX 4.30. I'm trying to port a tape
copying program from a BSD VAX and don't know if the problems I'm
having are endemic to cartridge tapes in general, or if DG's tape
driver is brain-damaged.
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 ?
Can I read and write EOF markers just like normal tapes ?
Do they use a double EOF to mark the logical EOT ?
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;
(2) cartridge tapes don't use double EOFs to delineate the
logical EOT;
(3) the driver doesn't handle the reading of two consecutive
EOFs correctly.
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.
Any pointers would be appreciated.
Richard Stevens
3M Health Information Systems, Wallingford, CT
stevens@hsi.com
... { uunet | yale } ! hsi ! stevensjgh@root.co.uk (Jeremy G Harris) (07/31/90)
In article <1849@hsi86.hsi.UUCP> stevens@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@root.co.uk +44 71 315 6600