Date: Tue, 15 Dec 1998 13:25:13 +1030 From: Greg Lehey <grog@lemis.com> To: mjacob@feral.com, Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <19981215132513.I15633@freebie.lemis.com> In-Reply-To: <Pine.LNX.4.04.9812141338310.2563-100000@feral-gw>; from Matthew Jacob on Mon, Dec 14, 1998 at 02:28:31PM -0800 References: <98Dec15.081550est.40374@border.alcanet.com.au> <Pine.LNX.4.04.9812141338310.2563-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 14 December 1998 at 14:28:31 -0800, Matthew Jacob wrote: > On Tue, 15 Dec 1998 08:16:29 +1100, Peter Jeremy wrote: >> Matthew Jacob <mjacob@feral.com> wrote: >> b) EARLY WARNING enabled: >> write(fd, buf, 1024) returns 512 >> [tape now at logical EOM] >> write(fd, buf, 1024) returns 0 [indicating logical EOM] >> write(fd, buf, 1024) returns 1024 >> write(fd, buf, 1024) returns -1, errno = EIO [512 bytes actually written] >> [tape now at physical EOM] > > The actual behaviour is more likely to be (assuming the app doesn't stop) > ... > b) I am proposing that behaviour be > >> write(fd, buf, 1024) returns N, where N is the amount actually written >> If, and only if N was 1024 (all bytes written) (and EOM had been > seen), the next write(fd, buf, 1024) returns 0 (0 bytes written). > > So, assuming the usual tape drive behaviour, the scenario as above would > be: > > i) write(fd, buf, 1024) returns 1024 (1024 bytes written) [ EOM flagged ] > ii) write(fd, buf, 1024) returns 0 (zero bytes moved) [ EOM cleared ] > iii) write(fd, buf, 1024) returns 1024 (1024 bytes written) > iv) write(fd, buf, 1024) will return -1 (ENOSPC or EIO - I don't care). > > It really doesn't matter what the app does at #iv- you've hit hard eot and > can't do anything but rewind or space backwards. > > It is expected that when #ii occurs the application could (in fact) write > a trailer record or two, but is expected to close the device or otherwise > cause a terminating filemark to be written and then rewind or do something > else. > > Alternatively, if the drive reports EOM *and* reports that it didn't write > all that was requested, then step #ii is ommitted entirely (as the goal of > signification has been met). Further, let's say we have a broken or stupid > drive, and it doesn't even report EOM (just that it didn't write all that > was requested)- this acts (or should act) as a significator to the user > application (there's absolutely no reason for a tape device, or for that > matter (sez Bob Snively of the ANSI SCSI committee) for any device, to not > write all that was requested *unless* some limiting condition (like > physical impossibility) occurs). I've probably missed something here, but what is the intention in (ii) or clearing EOM? What's wrong with: i) write(fd, buf, 1024) returns 1024 (1024 bytes written) [ EOM flagged ] ii) write(fd, buf, 1024) returns 0 (zero bytes moved) iii) write(fd, buf, 1024) will return -1 (ENOSPC or EIO - I don't care). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981215132513.I15633>