Clarification on SCSI presented data length for residual overflow/underflow determination

Pat LaVarre p.lavarre at ieee.org
Sat Jun 14 08:25:04 PDT 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406142_f.htm">HTML-formatted message</a>

@ software that essentially assumes a DataIn command that completes with a
residual count of zero
@ has completed successfully, thus ignoring SCSI check condition status for
UA and
@ causing data corruption.
Awesome war story, thank you.
Reminds me of humans writing Windows apps that corrupt data by wrongly
saying be happy just because
... the Ioctl returned a normal True, threw no abnormal False, and
... the Scsi returned a normal x00 Good, threw no abnormal x02 Check, and
no stranger abnormal result.
Well hello, going with just that much logic still leaves open the question,
did the Scsi throw a rare abnormal Data Residue, encoded obscurely as an
abnormal result in the deeply obscure Windows DataTransferLength field.
Running just that much logic gets all those rare cases exactly backwards,
wrongly concluding call passed when in fact call crashed.
That Windows Api by design set up the caller for astonishment. That
Api didn't give the caller a brief clear simple way to figure out whether
the call had thrown an abnormal exception or not. And soon enough the
human callers hit back, with misunderstanding of the astonishing cases.
Ain't no telling how a human will push back, after you push on them.



More information about the T10 mailing list