From owner-freebsd-arch Tue Dec 21 2:17: 0 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 28E5B153A3 for ; Tue, 21 Dec 1999 02:16:57 -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 LAA11444 for ; Tue, 21 Dec 1999 11:16:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA25195 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 11:16:54 +0100 (MET) Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 21EDA153B7 for ; Tue, 21 Dec 1999 02:16:19 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA07540; Tue, 21 Dec 1999 20:14:33 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) via SMTP by ren.detir.qld.gov.au, id smtpd007538; Tue Dec 21 20:14:25 1999 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA00353; Tue, 21 Dec 1999 20:14:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA26883; Tue, 21 Dec 1999 20:14:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost [127.0.0.1]) by nymph.detir.qld.gov.au (8.9.3/8.8.7) with ESMTP id UAA21880; Tue, 21 Dec 1999 20:14:23 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199912211014.UAA21880@nymph.detir.qld.gov.au> To: Bruce Evans Cc: Matthew Jacob , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath , syssgm@detir.qld.gov.au Subject: Re: filemarks? References: In-Reply-To: from Bruce Evans at "Tue, 21 Dec 1999 20:34:32 +1100" Date: Tue, 21 Dec 1999 20:14:22 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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