SCSI tape question
bqt at update.uu.se
Fri Dec 12 11:10:51 CST 2014
On 2014-12-12 17:54, 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
>> 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.
I don't know much of anything about the low level SCSI details here. So
I can't comment on that.
> 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.
Two tape marks is just a convention used by some software to indicate
the logical EOT. It has no special meaning for the hardware. In fact,
standard ANSI formatted tapes can legally contain two consecutive tape
marks without it being the EOT. ANSI instead have a special record to
More information about the cctalk