SCSI tape question
aek at bitsavers.org
Fri Dec 12 11:48:40 CST 2014
On 12/12/14 8:54 AM, Chuck Guzis wrote:
> On 12/12/2014 04:18 AM, Peter Corlett wrote:
>> My copy of the *draft* standard states "If the logical unit encounters a
>> filemark during a READ command, CHECK CONDITION status shall be returned and
>> the filemark and valid bits shall be set to one in the sense data" but perhaps
>> the final standard decided to be different for perverse reasons. Draft copies
>> of questionable provenance is what everybody's working from though, because the
>> final versions are $$$.
> Well, this is just odd--if I do my read not as variable length, but rather using specified block size and the "fixed" bit (bit 0 of byte 1 in the READ command), I do indeed get the filemark indication.
> I'll have a look at the *nix tape driver code, but AFAIK, the standard tape handlers for Linux and Unix depend on the block length being explicitly specified in a MODE SELECT command. When doing
> variable-length reads, this block length is 0.
This is bringing back a lot of bad memories..
You may want to look at
and John Wilson's tapeio routines
I've run into problems with tapecopy where it gets stuck in an infinite loop writing -1 byte
blocks if it ever runs into a bad block.
I'll have to look at the SCSI code I wrote back in 2001 for my direct SCSI tape reader on MacOS
but I'm pretty sure I ended up having to read fixed-length 64k blocks there.
This gunk was creeping back up on my todo list as I really do need to retire my G3 powerbook that
I use for tape reading, mostly because I've been 'upgrading' my servers and they no longer understand
AFP that OS9 uses.
More information about the cctalk