Data Out residual overflow/underflow handling
phughes at solidfire.com
Sat Sep 22 19:45:42 PDT 2012
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1209220_f.htm">HTML-formatted message</a>
One compelling reason to not allow an initiator to read 512 bytes from a
4KB block is that doing so might fool the initiator into thinking it was
reading contiguous 512-byte blocks at 512-byte LBA 0, 1, 2, etc. when in
fact it would be reading 512 bytes from the beginning of each 4KB block, in
essence reading 512-byte LBA 0, 8, 16, etc.
On Fri, Sep 21, 2012 at 6:14 PM, Pat LaVarre <p.lavarre at ieee.org> wrote:
> @ if you want to read a logical block you need to read it all, not just
> part of it.
> @ SCSI is called a 'block oriented" interface.
> @ initiators should issue a READ CAPACITY as part of discovery
> Last time I coded that test case in a Scsi target, not specifically an
> iScsi target, must be ten years ago now ...
> I let the Initiator read the 512 of 4096 bytes that kept it from crashing
> and I reported the Residue.
> Initiators careful enough to notice Residue were happy, because my Target
> reported the trouble.
> Initiators sloppy enough to ignore Residue were happy, because the next
> layer of software up the device driver stack got the chance to get its head
> straight, rather than having my Consumer Mass Market target returned as
> useless by the human who bought it Aftermarket and plugged it in.
> As yet me, I'm far too ignorant of iScsi to begin to guess which Target
> designs work well there. I'd guess Enterprise folk in particular might make
> different choices than won at Aftermarket.
> People who advocate Simple choices irrespective of Plug 'n Pray Pressures
> definitely would choose to throw a Check Condition and Kcq always.
> Signalling trouble in every possible way gives you your best hope of
> clueing in the Initiator who was so rude as to neglect the READ CAPACITY
More information about the T10