Skip site navigation (1)Skip section navigation (2)
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>