12 Dec
2014
12 Dec
'14
7:24 p.m.
On 12/12/2014 10:54 AM, Chuck Guzis wrote:
On 12/12/2014 04:18 AM, Peter Corlett wrote:
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
packet.
Jon
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.