Subject: Re: (2nd send) opinion sought about EOM handling for tapes
To: Stefan Grefen <grefen@hprc.tandem.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 07/14/1998 10:06:04
On Tue, 14 Jul 1998, Stefan Grefen wrote:

> Fine with me.
> 
> > 
> > 
> > 	C) Additional features that provide seamless tape volume
> > 	management become part of a vtape(4) pseudo-device. This
> > 	should also include vault and robotics management, label (VSN)
> > 	management, as well tape striping.
> > 
> > 	The design and implementation of vtape(4) timeframe TBD.
> 
> Anybody interested in working on this??

	..Madame, if we had but world enough and time,
	this coyness of your would be no crime....

	..The grave is a fine and quiet place,
	but none there do I think embrace...

couldn't resist.. I split the two projects apart on purpose. I'm
interested in vtape, but not immediately. 

> > 
> > 
> > 	EARLY WARNING behaviour enabled is defined as a guarantee that
> > 	if early warning (logical EOM) is detected, the tape driver
> > 	will ensure that the writing application will be notified by
> > 	a 'short' write (non-zero residual). This may be delivered
> > 	by either the EOM itself causing a residual, but also may
> > 	require the driver to internally 'note' that EOM has occurred
> > 	and to terminate the next write immediately with the residual
> > 	set to the byte count of that request.
 
> From your previous proposal I assumed that I get either a 'real' residual 
> if the request didn't fit on physical tape or a residual == request_size
> if it did fit. If 0 bytes fit on tape I get an EIO.
> Is this correct? 

No. 

Here's two examples (assuming EARLY WARNING behaviour enabled):

Case 1)

	N = Write(fd, buf, AMT) ==>
			Succeeds, Residual == 0, N gets set to AMT..
	...
	...

	N = Write(fd, buf, AMT) ==>

			Succeeds, but not all of data written, check
			condition set, SENSE data has (likely)
			NO ADDITIONAL SENSE in sense key, EOM bit set.

			N gets set to amount actually written (i.e.,
			0 <= N < AMT). Driver notes that EOM has been hit.

	Choice #A ('correct' application behaviour):

		Since N != AMT, tape is now full. Close and rewind. Close
		operation causes FileMark(s) to be written.
		Ask for another tape. Operate changer. Whatever.

	Choice #B ('relentless' application behaviour):

		N = Write(fd, buf+N, AMT-N) (to attempt to finish last
			write which didn't 'succeed')
		...
		N = Write(fd, buf, AMT)....
		[ repeat until ]

			Hard EOT reached. Check condition. VOLUME
			OVERFLOW set in sense key. Return EIO to
			user.

		(Note that this is the same as w/o EARLY warning enabled)

Case 2)

	N = Write(fd, buf, AMT) ==>
			Succeeds, Residual == 0, N gets set to AMT..
	...
	...

	N = Write(fd, buf, AMT) ==>

			Succeeds, and all of data written, check
			condition set, SENSE data has (likely)
			NO ADDITIONAL SENSE in sense key, EOM bit set.
			N Set to AMT. Driver notes that EOM has been hit.

	(application continues- after all, why shouldn't it? It has
	not been signalled that something different has occurred).

	N = Write(fd, buf, AMT) ==>
			Driver returns right away with N set to 0,
			signalling logical EOM.

	Choice #A ('correct' application behaviour):

		Since N != AMT, tape is now full. Close and rewind. Close
		operation causes FileMark(s) to be written.
		Ask for another tape. Operate changer. Whatever.

	Choice #B ('relentless' application behaviour):

		N = Write(fd, buf+N, AMT-N) (to attempt to finish last
			write which didn't 'succeed')
		...
		N = Write(fd, buf, AMT)....
		[ repeat until ]

			Hard EOT reached. Check condition. VOLUME
			OVERFLOW set in sense key. Return EIO to
			user.

		(Note that this is the same as w/o EARLY warning enabled)





> BTW what are the return codes for a filemark after a EARLY WARNING??

>From the device? It depends. Usually all is well until you hit
hard EOT.