Date: Tue, 21 Dec 1999 20:14:22 +1000 From: Stephen McKay <syssgm@detir.qld.gov.au> To: Bruce Evans <bde@zeta.org.au> Cc: Matthew Jacob <mjacob@feral.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, freebsd-arch@freebsd.org, 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>, syssgm@detir.qld.gov.au Subject: Re: filemarks? Message-ID: <199912211014.UAA21880@nymph.detir.qld.gov.au> In-Reply-To: <Pine.BSF.4.10.9912211946160.11122-100000@alphplex.bde.org> from Bruce Evans at "Tue, 21 Dec 1999 20:34:32 %2B1100" References: <Pine.BSF.4.10.9912211946160.11122-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 21st December 1999, Bruce Evans wrote: >> > 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. That looks fine to me, though I don't consider slavish POSIX adherence necessary. The model I'm proposing is slightly different to everyone else's (of course), and alternates "return 0" and "normal write" after the early warning mark until physical end of media is hit, then "return -1" with errno = ENOSPC (even though I think a few Unices get by with EIO). Thus, 0 means "there is some space, but not this time". :-) We should consider the nature of programs that will write to tape. How should "cat" work when writing a tape? I expect it would write until physical end of media with this model and run the 1/2" tape right off the reel. That would be fine by me since "cat" is not a normal tape writing program. For modern tapes even "cat" will stop at the physical end of tape. Does anyone have evidence that writing like this would corrupt the last block, or be otherwise unreadable, even on different OSes? So far, Rod has suggested that problems could exist here. I'd like firm details. I can only test on FreeBSD and Solaris/Sparc. Normal tape programs probably already recognise the end of media detection methods we are considering, and probably work with all of them. In particular my reading of dump and tar suggests that they will work with my formula, with Matt's, and with Rod's, as they accept -1/ENOSPC, partial write, and zero length write as signals to stop. Looks like dd already supports this stuff too. I expect that the only proposed model with no current support in the tree is John's. I don't like the idea of signals in this context. Are there any more models, to confuse the situation further? :-) By the way, I don't recall any disagreement about reading filemarks. (Physically write 2 filemarks only on 1/2" tape, but simulate 2 on everything else.) Is this part now settled? Stephen. 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?199912211014.UAA21880>