Date: Sun, 21 Mar 1999 16:17:44 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: scsi@FreeBSD.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Message-ID: <199903212317.QAA22633@narnia.plutotech.com> In-Reply-To: <Pine.LNX.4.04.9903200922300.32608-100000@feral-gw> <199903210039.RAA20800@narnia.plutotech.com> <19990321112050.05515@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19990321112050.05515@uriah.heep.sax.de> you wrote: > As Justin T. Gibbs wrote: > >> 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. > > So we are in violent agreement then? :) Yes. >> I still believe that returning a real >> error at EOT is correct. > > I could live with ENOSPC, but only iff no data have been written at > all in a particular request. Iff something has been written, the > `short write' is IMHO the correct way that's compatible with other > usage of write(2) throughout Unix, so the caller can be notified that > their request only partially succeeded (but succeeded so far). Yes. If anything is written, you must return the amount of data successfully written. The program will see the ENOSPC on the next attempted write. >> dump understands ENOSPC, and should work correctly if ENOSPC >> is still returned at EOM or EOT. > > Probably. I think part of the problem dump's algorithm doesn't > (didn't?) is that EIO has been reported, as opposed to ENOSPC. Yes, I modified dump around the time that CAM was integrated into the tree. -- 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?199903212317.QAA22633>