From owner-freebsd-arch Mon Dec 20 23:49:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E4D2E153C8 for ; Mon, 20 Dec 1999 23:49:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA07257 for ; Tue, 21 Dec 1999 08:49:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA24335 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 08:49:40 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9685814E6B for ; Mon, 20 Dec 1999 23:49:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA14707; Mon, 20 Dec 1999 23:51:18 -0800 Date: Mon, 20 Dec 1999 23:51:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: <199912210729.XAA45172@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ 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