Date: Mon, 14 Dec 1998 10:57:58 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <Pine.LNX.4.04.9812141047030.2563-100000@feral-gw> In-Reply-To: <199812141839.FAA11479@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9812141047030.2563-100000>