Date: Tue, 21 Dec 1999 20:34:32 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Jacob <mjacob@feral.com> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, 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.9912211946160.11122-100000@alphplex.bde.org> In-Reply-To: <Pine.BSF.4.10.9912202333570.56276-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Dec 1999, Matthew Jacob wrote: > 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 I think this stretches the POSIX API too far. [write() shall attempt to write the amount given, and return -1/ENOSPC if there is no space.] Only a very feeble attempt would successfully write 0 bytes when there is some space. > 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. This amounts to pretending that the device is smaller than it is. Reverting to POSIX behaviour (returning a short count, then -1/ENOSPC) would be just as good for programs that don't understand EARLY_WARNING. > 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 I don't think signals are appropriate here. > 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. Before trying anything new, you should try fixing the longstanding Free(?)BSD bug of not actually implementing this API. Short counts are rarely returned for writes to devices. Instead, an error is returned and the (short) amount written is forgotten :-(. This is because most drivers return short writes as an error, with the amount written in (original auio.uio_resid) - (auio.uio_resid), and the sys_generic.c level only converts the error to a non-error if the amount written is nonzero when the error is ERESTART, EINTR or EWOULDBLOCK. There are similar problems with error handling for reads. There are related but different problems for writes to full filesystems. > > We seem to have 3 cases when Early Warning is detected: > > ... > > 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. This is in narrow or nonexistent usage. POSIX requires returning -1/ENOSPC if "there is no space on the device". The only reasonable interpretation of a return value of 0 is that there is some space, but not this time. Bruce 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.9912211946160.11122-100000>