From: jeremy@classic.asd.sgi.com (Jeremy Higdon)
Subject: Re: bug in SCSI tape driver or tps man page ?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 8 Oct 1992 20:13:53 GMT

In article <3024@contex.contex.com>, jeff@hobbes.contex.com (Jeff Carey) writes:
> Let me throw away all previous (jumbled) correspondence and start
> from the beginning.
> 
> We have this tape (an ANSI-type tape):
> 
> seven 80-byte blocks,
> a filemark,
> ten 16K-byte blocks,
> a filemark,
> six 80-byte blocks,
> and two ending filemarks.
> 
> We execute this sequence of commands on the tape:
> 
> At the BOT,
> open tape for reading,
> read seven 80 byte blocks,
> forward space three (3) filemarks,
> try to "read" a block,   (NOTE: prior to read is the position in question)
> close tape.

Before the last read, it is between the last two filemarks.  When
you issue the read, it hits the last filemark and silently retries.

> 
> Now, where should the tape be positioned before the last read???
> In practice it ends up at the end of both EOD filemarks (the last read returns
> -1: No space left on device).
> Logically, it would end up between the EOD filemarks and the last read would
> read 0 bytes and return 0.
> 
> We have this "man tps" excerpt:
> 
>      1.	 If the	first read after an open encounters a filemark before
> 	 transferring any data,	and the	tape was not known to be at the	top of
> 	 a filemark or BOT, the	filemark will be skipped, and the read
> 	 retried.  Any further errors will be reported exactly as they occur.
> 	 In particular,	if two sequential filemarks are	found, the tape	will
> 	 be positioned between them in this case.
> 
> and this "man jagtape" excerpt, which, by the way, is different from above:
> 
>      1.	 If the	first read after an open or following a	BSF encounters a
> 	 filemark before transferring any data,	and the	tape was not known to
> 	 be at the top of a filemark or	BOT, the filemark will be skipped, and
> 	 the read retried.  Any	further	errors will be reported	exactly	as
> 	 they occur.

This accurately describes the jagtape behavior.

> 
> and this corrected "man jagtape" excerpt, which is what Jeremy corrected
> due to "a bug in the tpsc driver":

It was supposed to describe the tpsc behavior.  So calling it a corrected
"man jagtape" is a bit misleading.

> >     1.  If the first read after an open or following a BSF encounters a
> >         filemark before transferring any data,                              
> >                                             the filemark will be skipped, and
> >         the read retried.  Any further errors will be reported exactly as
> >         they occur.

I took another look at the 4.0.5 tpsc driver (I did not work on it, so there
is no warranty on this interpretation), and near as I can tell, it should say
the following:

	If the first read after an open or following a FSF, FSR, or BSR,
	WFM, or a (SETMARK with a count of 1 done after a read in which
	you ended up at a filemark) encounters a filemark before transferring
	any data . . . .

So, you issue a read, followed by an FSF.  Then you encounter a filemark
before transferring any data, so the read is retried and further errors
(the EOD) get reported as they occur.


> 
> The above three descriptions
> have been enough to convince Jeremy and Dave that what I am seeing as the
> above-mentioned "tape position at the last read" is correct.  But, I
> disagree.  What I mentioned in my last post is that the read to determine
> position is done immediately following an FSF.  No where in any of the above
> three MOVEMENT CRITERIA descriptions does it mention that the filemark would
> be skipped if the first read following a _FSF_ encounters a filemark.
> 
> So, is this a bug with the driver or the man pages?

I think the man page is the way it should be, and the driver is wrong, but
that's just my opinion.

> 
> -jeff

jeremy