Subject: Re: (2nd send) opinion sought about EOM handling for tapes
To: Matthew Jacob <mjacob@feral.com>
From: Stefan Grefen <grefen@hprc.tandem.com>
List: tech-kern
Date: 07/14/1998 17:57:55
In message <Pine.LNX.3.93.980713073235.16709A-100000@feral-gw>  Matthew Jacob wrote:
> 
> 
> How is this for a proposal?
> ------------------------------

[...]

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??

> 
> 
> 	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? 
The policy here has to be unambigous so that the application knows after a
write if the data is on tape or not without a further operation.
BTW what are the return codes for a filemark after a EARLY WARNING??


[...]

Stefan
> 
> -matt
> 
> 
> 
> 
> 

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---