Data Out residual overflow/underflow handling

Knight, Frederick Frederick.Knight at netapp.com
Tue Sep 25 12:14:54 PDT 2012


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

FCP gives devices 3 choices (you ask for 1 block=4K bytes, but only supply
512 bytes):
If the command requested that data beyond the length specified by the FCP_DL
field be transferred, then the device server shall set the FCP_RESID_OVER bit
(see 9.5.8) to one in the FCP_RSP IU and:
a)	 process the command normally except that data beyond the FCP_DL
count shall not be requested or transferred;
b)	 transfer no data and return CHECK CONDITION status with the sense
key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD
IN COMMAND INFORMATION UNIT; or
c)	     may transfer data and return CHECK CONDITION status with the
sense key set to ABORTED COMMAND and the additional sense code set to INVALID
FIELD IN COMMAND INFORMATION UNIT.
Choice a) was for devices that knew their hosts looked at residual; take the
data and write it with no CC returned.	No mention of what data gets written
(zeros, garbage, read/modify/write, random, etc…)
Choice b) was for devices that wanted to protect their data at all costs;
just return CC.  NO data is transferred.
Choice c) was for the wish/washy; some data may be transferred, or maybe not;
but either way, return a CC.  Again, no mention of what does get written, if
any (since maybe none gets written; maybe).
I suppose you could select choice a) for a READ to LBA zero, and then select
b) for all WRITES, and select c) for other READs.  But, it depends on the
support your host provides.
		Fred Knight
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Black, David
Sent: Monday, September 24, 2012 9:22 AM
To: Pat LaVarre; t10 at t10.org
Subject: RE: Data Out residual overflow/underflow handling
In this particular case, we’re dealing with a write that *will* corrupt
data because the logical block size is wrong.  A CHECK CONDITION is
definitely appropriate, and I could even argue for an iSCSI Reject PDU in
response to more firmly tell the clue-impaired initiator to go away - that is
a stretch, though, and I think CHECK CONDITION w/ILLEGAL REQUEST and no data
written is the better response.
SCSI has support for small logical blocks on larger physical blocks - see the
LOGICAL BLOCKS PER PHYSICAL BLOCKS EXPONENT field in the parameter data
returned by READ CAPACITY (16).
Thanks,
--David
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pat LaVarre
Sent: Sunday, September 23, 2012 12:14 PM
To: t10 at t10.org
Subject: Re: Data Out residual overflow/underflow handling
I think I agree with every word except we lose me at 'compelling'?
Got more?
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.
Paul
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 Discovery.



More information about the T10 mailing list