Date: Sat, 20 Mar 1999 17:39:47 -0700 (MST) From: "Justin T. Gibbs" <gibbs@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 Message-ID: <199903210039.RAA20800@narnia.plutotech.com> In-Reply-To: <Pine.LNX.4.04.9903200922300.32608-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.LNX.4.04.9903200922300.32608-100000@feral-gw> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903210039.RAA20800>