SCSI tape question

[Peter Corlett]

On Thu, Dec 11, 2014 at 06:50:53PM -0800, Chuck Guzis wrote:
[...]
> Now, when I come to a filenark, I'm expecting that the filemark bit (bit 7)
> will be set in the sense key.  It doesn't happen, the result just comes back
> as 0 bytes read and a normal (NO_SENSE) sense result.  The additional sense
> code and sense qualifier bytes are also 0.

> Is this normal behavior?  I'dve thought that the filemark bit would be set in
> every case of a filemark being read.  My X3T9 documents don't mention this
> behavior, but maybe I missed something.

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

Note that there are *three* different types of end-of-X event with tape:
end-of-file at a filemark, end-of-medium indicating the logical end of the
recording, and end-of-tape where it's flapping off the reel (which is always
"fun" when it happens to QIC cartridges).  If the tape has been reused, there
may be data between end-of-recording and end-of-tape, but you're probably not
going to get at it from SCSI-space.

The behaviour you describe dovetails nicely with the POSIX API which indicates
EOF by returning zero to a read() call.  On Linux, the next read() call then
starts reading the next file.  I had to check the man page to remind me what
happens at end-of-medium: it's indicated by two consecutive EOFs followed by
"an error" (not stated, but EIO seems likely), which can alternatively be
viewed as an empty file followed by something to break applications that didn't
take the hint the first time.

Anyway, this suggests an alternative API that your drive might be (incorrectly)
providing, and perhaps you will get two sequential zero-length reads and/or a
sense error and filemark bit only at end-of-medium.

I would certainly also check out the source for Linux's SCSI tape driver.  The
Linux kernel takes a somewhat pragmatic approach in the face of dodgy hardware,
so there are loads of edge cases with accompanying rants explaining in
technical detail just why such-and-such a device is a steaming pile.