SCSI tape question
elson at pico-systems.com
Fri Dec 12 21:24:38 CST 2014
On 12/12/2014 10: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.
> And yes, I can read past double filemarks and get to the
> previously written data. Eventually, a blank media or EOM
> condition arises and calls a halt to things. Recently, I
> ran into a case where the double-filemark was an
> accident--a zero-length file was written, so the
> disrespect for double filemarks is necessary.
> I've got an old X3T9 spec here, as well as a few vendors'
> manuals and the strange non-filemark behavior isn't
> detailed--however, it's simple enough to translate this
> into the expected "filemark-sensed" code.
> It's not a stumble, just curiosity.
LOTS of SCSI devices violated the standard protocol in
interesting ways. My understanding
is there are two classes of SCSI drives. One class used a
scheme that was quite like old
9-track tapes, so that there was essentially no formatting
that wrapped around the user
data. So, there would be a physical gap with no magnetic
transitions between the
written user data blocks. There would be a CRC of some sort
at the end of the user
data. Higher-end drives wrapped the user data into a more
complex format, so each
block would have a block size and a sequence number at the
beginning, and maybe
a trailer of the same info with the CRC. Often in these
systems, there would be NO
physical gap. This increased data capacity, but made it
impossible to rewrite a single
tape block. The file mark was just a special block with
minimal or zero-length data
More information about the cctalk