From owner-freebsd-current Mon Dec 14 10:58:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26093 for freebsd-current-outgoing; Mon, 14 Dec 1998 10:58:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26082 for ; Mon, 14 Dec 1998 10:58:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id KAA03076; Mon, 14 Dec 1998 10:57:58 -0800 Date: Mon, 14 Dec 1998 10:57:58 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Bruce Evans cc: freebsd-current@FreeBSD.ORG Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour In-Reply-To: <199812141839.FAA11479@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >Yes, it could be fixed in this way, I suppose, but I don't believe that an > >error condition should be signalled- a signification condition that early > >warning has been reached isn't an error- at least for tape drives. What is > >it for other character devices? > > Returning an error (or EOF for the read case) from the strategy routine > is the only legitimate way to stop physio(). No EOF for the write case? > > Ttys return EIO after certain errors and than read/readv/write/writev > return the wrong value (-1/EIO) if the EIO occurred after successfully > completing some i/o. > All I want to see is that the actual number of bytes written gets succesfully propagated back to the application and that the user application can get some kind of warning the physical EOT is near. If you think that fixing the read/readv/write/writev is the way to go, like, solid, man.... It makes state management in the tape driver easier! But here's the kicker- nearly all the time that tapes report early warning, they actually have written all the data. Under the model you're proposing, then no signification will make it back to the user application since the tape driver will complete such commands as having an error (EIO) but all data was 'successfully' (this seems wierd to me) written (and you'll have tossed the EIO). Without the signification, then you'll always write up until physical EOT where you'll get VOLUME OVERFLOW. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message