Date: Mon, 20 Dec 1999 09:39:47 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: John Polstra <jdp@polstra.com> Cc: Hauke Fath <hf@Melog.DE>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Thomas David Rivers <rivers@dignus.com>, Bob Bishop <rb@gid.co.uk>, Greg Lehey <grog@lemis.com>, Stephen McKay <syssgm@detir.qld.gov.au>, phk@freebsd.org, scsi@freebsd.org Subject: Re: filemarks? Message-ID: <Pine.BSF.4.05.9912200924410.32761-100000@semuta.feral.com> In-Reply-To: <XFMail.991220091856.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > By my reading, POSIX doesn't allow that behavior. It says (section > 6.4.2.2): > > If a write() requests that more bytes be written than there is > room for (for example, the physical end of a medium), only as > many bytes as there is room for shall be written. For example, > supppose there is space for 20 bytes more in a file before > reaching a limit. A write of 512 bytes would return 20. The > next write of a nonzero number of bytes would give a failure > return (except as noted below). > > That last sentence precludes the application from continuing writing > beyond the early warning. The "except as noted below" doesn't seem to > refer to anything relevant here. Hmmm.... Here's another try at this: 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 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. This makes a tape more akin to a tty device that dropped DCD (:-)). At any rate, I think that POSIX semantics are adhered to in this case, but there is at least some attempt to have a signification condition other than a hard error and still allow trailer records to be written. The last paragraph also leaves wiggle room for possible future delayed buffering. Another way to do this would be to use the Solaris model, which is a little harder to implement (more tape state has to be maintained). Thoughts? -matt p.s.: and thanks for the positive discussion on this! Finally we may be able to get somewhere .... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" 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.05.9912200924410.32761-100000>