Date: Mon, 20 Dec 1999 23:51:18 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: freebsd-arch@freebsd.org, Stephen McKay <syssgm@detir.qld.gov.au>, Greg Lehey <grog@lemis.com>, Bob Bishop <rb@gid.co.uk>, Thomas David Rivers <rivers@dignus.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, Hauke Fath <hf@Melog.DE> Subject: Re: filemarks? Message-ID: <Pine.BSF.4.10.9912202333570.56276-100000@beppo.feral.com> In-Reply-To: <199912210729.XAA45172@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ this is a thread moved from scsi to -arch at the request of a couple of
people. I proposed (revisited) some tape EOM handling changes. The
latest proposal I had worked out to:
Write Behaviour near End of Media
A user application detects EARLY WARNING during writing by
getting a return from the write(2) system call of zero
(zero bytes were written). If the device open is the
non-rewinding tape device, the application may close and
reopen it and continue writing until physical end of medium
(EOT) is reached, whereupon a value of -1 is returned from
the write(2) system call and the system error is set to
ENOSPC. A filemark will be written in the usual manner if
EARLY WARNING is detected and the application closes the
tape device at that point. It is unlikely that filemark(s)
can be written after physical EOT is detected. If the user
applications does not close the device and continues to
attempt to write after EARLY WARNING notification, a value
of -1 will be returned with the system error set to ENOSPC.
Some tape devices may be configured such that they do not
report EARLY WARNING, in which case the physical EOT
notification as described above will occur first.
If a user application writes to EARLY WARNING, closes and
rewinds the tape device, and later reopens it and seeks to
the end of recorded media and starts writing again, EARLY
WARNING detection may or may not be defeated, in which case
physical EOT notification will occur as described above.
If the tape device is set in fixed block mode, EARLY WARNING
may or may not be able to be successfully detected and
signified to the user application as described above.
John Polstra is proposing using signals to signify EARLY WARNING. Rodney
has responded with the mail below. This is all archived in mailling
lists... ]
> The API has a perfectly acceptable and working mechanism to deal with
> this.
>
> RETURN VALUES
> Upon successful completion the number of bytes which were written is re-
> turned. Otherwise a -1 is returned and the global variable errno is set
> to indicate the error.
>
> We seem to have 3 cases when Early Warning is detected:
>
> a) The write(2) completed, all data has been written to the tape. Here
> by definition we should simply return nbytes, after all, nothing is
> wrong at this point, all the data did make it onto the tape. The
> driver layer should set a flag at this point noting that Early Warning
> has been seen but not delivered to the consumer. This flag will be
> delivered by c) below, since the driver layer knows not to try and
> put any more data on the tape.
>
> b) The write(2) was not completed, some bytes did make it to the tape.
> If _some_ bytes made it we should return how many did and set the
> Early Warning flag as in a). If no bytes made it we return 0, which
> is a degenerative case, no quite covered by the definition of
> RETURN VALUE but in wide usage.
>
> c) The write(2) was not able to put any data on the tape. Return -1, NOSPC.
>
>
> Whats wrong with this model?
The user application cannot distinguish EARLY WARNING from hard EOT directly.
You can put more data on tape after EARLY WARNING and before hard EOT.
But the model I'm proposing continues to doesn't use -1, and allows the
application to continue to write past EARLY WARNING should it choose to do so.
That's my primary concern for writes. If it's that important for everyone,
it could all be a -1 indication, but something has to signify the difference
between EARLY WARNING and hard EOT. John wants signals- that seems a bit
much- particularly if it overlaps usage in and/or kills off the unaware
user application.
Read behaviour wrt double filemarks I've also stated (and I'll restate
for the -arch audience) (yes, I was shot down about this a while ago,
but there are a bunch of us folks who actually use modern tape devices
who don't much like the way things are)
[ From previous mail: ]
----------
A user application detects a filemark by getting
a return from a read(2) of less than the nbytes
argument to the read(2) system call.*
A user application detects EOD by getting at least
two read(2) system calls in a row returing a value
of zero (indicating no data transferred).*
A user application detects an error by getting a value of
-1 returned from the read(2) system call. The system error
will contain EIO indicating an I/O error or some other
value indicating why the operation could not occur. If
EIO is returned, tape position has been lost and the
application must either close the device (for an automatic
rewind if the rewinding device was opened), specifically
rewind or offline the device, or issue an MTEOM MTIOCTOP
ioctl, or leave these actions for another application to
perform.
The '*' points above may require some condition synthesis by the driver,
but not to as complex a level as some systems. For example, BLANK CHECKs
during read would not return -1 (just indicate a zero length read return).
---
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912202333570.56276-100000>