On 06/10/2015 11:12 AM, Mark J. Blair wrote:
On Jun 10, 2015, at 08:46, Al Kossow <a...@bitsavers.org> wrote:
On 6/10/15 8:15 AM, Mark J. Blair wrote:
And that is precisely why I'm thinking of an ad-hoc interface rather than just
plugging a SCSI drive into a UNIX box.
It also has the advantage that you can return the CRC/checksum and partially
read blocks. Most SCSI tape drives don't
return the data if the read doesn't succeed.
I particularly like the idea of being able to extract questionable data and
CRC/checksum.
Ok, now three more questions come to mind:
1) Is it ever acceptable to mix densities on a single tape? I'm not sure that
my Kennedy drive will even allow that, but I don't know if that is universal.
No, never OK. There is a format ID written OVER the BOT marker for 1600
and 6250 that tells the drive what the density format is. If you EVER
see the density change, is is because a tape was partially overwritten
at a different density, and then you've either read off the end of the
re-written portion, or the last EOF was lost somehow.
2) What's the scoop on a final record overlapping the EOT marker? Or even a new
record starting after the EOT marker? I seem to recall reading about some
applications that stuck data after the EOT, such as backup volume information.
Yeah, the EOT sensor is only an inch or so ahead of the write head, so
any long record will overlap the EOT sensor, and then the trailer and
EOF records will have to continue on past that for a few additional inches.
3) Did anybody ever go over to the dark side and implement copy protection on
magtapes, say, by deliberately including a record with bad CRC that a normal
driver+drive would not support writing? Or was that evil limited to the floppy
disk world?
UGH! You can't guarantee this would work on different vendor's hardware.
Jon
