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