SCSI tape question

[Jon Elson]

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
packet.

Jon