Date: Mon, 14 Dec 1998 09:13:06 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: freebsd-current@FreeBSD.ORG Subject: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <Pine.LNX.4.04.9812140901020.2563-100000@feral-gw>
next in thread | raw e-mail | index | archive | help
(This may not be the correct forum for this discussion- but I wanted to
include *users* as well as *developers* of FreeBSD)
I'll throw this out for opinions- I'd like to make change (close to what I
did for NetBSD) to the default behaviour for how early warnings on writes
are handled.
The section below is from the man pages in NetBSD- I'd like to actually
make EARLY WARNING default behaviour. Opinions, please... I have the hood
open on the tape driver busily fixing(breaking) things so I'd like to get
a sense of what people would like before marching much further.
This is one of several changes under consideration.
The others for immediate implementation are:
+ forcing variable mode for tape devices unless quirked otherwise
(I have a test prototype of this already working)
+ correct implementation of 2 FM@EOD (only needed for tapes that
do *not* have a space to end of recorded media function
(basically only 1/2" Reel drives)
+ Hardware/SCSI/Logical Block reporting && positioning
+ SCSI error reporting via the MTIOCSTATUS command, possibly an
auxillary MTIO command to get full (all of) previous SCSI Sense
Data.
Down the road a little bit would be:
++ untangling the minor device as behaviour selector so that
ioctl's would not have to be used to select compression.
++ Persistent vs. per-mount device properties and reservation.
++ Proper handling of deferred errors
Anyway- here's the Early warning man page clip- please let me know what
y'all think:
EOM HANDLING
Attempts to write past EOM and how EOM is reported are handled slightly
differently based upon whether EARLY WARNING recognition is enabled in
the driver.
If EARLY WARNING recognitions is not enabled, then detection of EOM (as
reported in SCSI Sense Data with an EOM indicator) causes the write oper-
ation to be flagged with I/O error (EIO). This has the effect for the
user application of not knowing actually how many bytes were written
(since the return of the read(2) system call is set to -1).
If EARLY WARNING recognition is enabled, then detection of EOM has no im-
mediate effect except that the driver notes that EOM has been detected.
If the write completing didn't transfer all data that was requested, then
the residual count is returned to the user application. In any event, the
next attempt to write (if that is the next action the user application
takes) is immediately completed with no data transferred, and a residual
returned to the user application indicating that no data was transferred.
This is the traditional UNIX EOF indication. The state that EOM had been
seen is then cleared.
In either mode of operation, the driver does not prohibit the user appli-
cation from writing more data, if chooses to do so. This will continue up
until the physical end of media, which is usually signalled internally to
the driver as a CHECK CONDITION with the Sense Key set to VOLUME OVER-
FLOW. When this or any otherwise unhandled error occurs, an error return
of EIO will be transmitted to the user application. This does indeed
mean that if EARLY WARNING is enables and the device continues to set EOM
indicators prior to hitting physical end of media, that an indeterminate
number of 'short write returns' as described in the previous paragraph
will occur. However, the expected user application behaviour (in common
with other systems) is to close the tape and rewind and request another
tape upon the receipt of the first EOM indicator.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9812140901020.2563-100000>