From owner-freebsd-scsi Sat Mar 20 16:49:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 86B7F14CC2 for ; Sat, 20 Mar 1999 16:49:11 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id RAA20800; Sat, 20 Mar 1999 17:39:47 -0700 (MST) Date: Sat, 20 Mar 1999 17:39:47 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903210039.RAA20800@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > >> >> > There was a lot of discussion about this some months back. The >> > consensus (which I didn't agree with) was that EIO should still be >> > propagated at early warning (the EOM bit in Sense Data- not the >> > VOLUME OVERFLOW which is hard physical EOT) rather than using a >> > (possibly deferred) residual count to an I/O operation to provide >> > the signification. >> >> Btw., i don't agree to this either, and we've had this before. If >> some data have been written, a `short write' should be returned to the >> application, and no error set (yet - unless the application attempts >> to continue writing). Only iff no data have been written at all, an >> error should be flagged (and that was my part of a compromise in a >> previous discussion with Justin -- i originally thought an error >> should never be flagged, just a `0 return', but i agree i've been >> wrong in this). > > No- I think you're right on this but we've been overrulled. > > Did you really have an agreement with Justin that the only time an error > is returned is if no data was writtent at all? I can guarantee you that > you'll always write up to hard EOT if this is the case. The only thing I recall about this was whether we should return ENOSPC or continually return 0 on EOM/EOT. If we decide to simply "pause" at EOM (i.e. return a short write or a 0 length write), then this is fine by me. I still believe that returning a real error at EOT is correct. dump understands ENOSPC, and should work correctly if ENOSPC is still returned at EOM or EOT. I believe that dump only cares about EOT because of the way it does its error handling, but I would have to look at the code again. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message