Data Out residual overflow/underflow handling
p.lavarre at ieee.org
Sun Sep 23 09:13:34 PDT 2012
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1209231_f.htm">HTML-formatted message</a>
I think I agree with every word except we lose me at 'compelling'?
Must the rules be the same for zero and nonzero Lba's?
Like is disagreement between Initiator and Target over whether Lba 1 is at
byte offset 4096 or 512 a Compelling argument to throw Kcq when the Initiator
calls to Read Lba 0 in iSCSI?
Me, when Discovery went wrong, I saw us not execute the Pattern of keeping
the system most simple, like by fixing the bug where it was, in the
Initiator's weak Discovery that wrongly concluded 512 bytes per Logical Block
without benefit of a necessary Read Capacity probe.
Sure I hear other markets deliver Keep it most simple by Customers &
Suppliers pulling forward together as partners who talk together meaningfully
enough to give significant surprising unplanned work discovered in
Integration Test to whomever should have anticipated the work.
Me, ten years and two employers ago, I was in Consumer Mass Market, indeed
Aftermarket substitutes for HDD & CD-R.
So I saw us execute the Pattern of She who ships first wins. We didn't recall
and update the broken Initiator. We grew the House of Cards. We complicated
the Aftermarket Target that arrived later.
We made the Read of Lba 0 pass not crash by consciously choosing Not to Throw
Kcq, instead throwing only Nonzero Residue in parallel.
I don't know of that's a choice available in iSCSI? Maybe iSCSI got around to
instituting the simplification of requiring a Kcq from the Target to explain
every instance of Nonzero Residue caused by the Target?
Lba 0 throwing no Kcq was compromise adequate to unblock enough paying
customers to please the people Qual'ling us.
The wrong-headed low-level early-in-boot hard-to-update BIOS software that
did Discovery incorrectly as if HDD and CD-R were all the world, that BIOS
then kept running incorrectly, not crashing, long enough to let the layer
above take over and get straight,
The evil consequences of our Making the system less simple, those we did not
track. Those costs we externalised.
Sent from my iPhone
On Sep 22, 2012, at 7:45 PM, Paul Hughes <phughes at solidfire.com> wrote:
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
@ 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 Discovery.
More information about the T10