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/13/1998 07:47:05
Okay- I've been doing some rethinking...
How is this for a proposal?
------------------------------
A) Current tape behaviour is unchanged by default with respect
to EOM handling.
B) New code is added which provides an EARLY WARNING behaviour
(see below). This is controlled by an MTIO ioctl, and its
default state is as disabled (as in #A above), but may be
enabled if an ST_EARLY_WARNING option is defined.
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.
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.
No other changes are proposed. If an application does nothing, the
same behaviour that occurs now will still occur. If an application
enables early warning behaviour, or a kernel that has the behaviour
defined on by default is running, then at most one early warning indicator
will be delivered to the application. The application can continue
to write until hard (physical) EOT (or past, if possible) if it chooses.
The current behaviour at hard (physical) EOT will be preserved (EIO
is returned). If early warning is enabled, the implication with respect
to error codes is that no EIO will be returned until hard (physical)
EOT is encountered (barring some other error condition, e.g. MEDIA
ERROR).
No changes with respect to filemarks is proposed.
-------------------------------------------------
[ Bottom line: I'm just really interested in early warning- all the
rest I could live with ]
Will this do for y'all?
-matt