[stgt] stgt: residual on Inquiry

Joe Eykholt jeykholt at cisco.com
Wed Aug 11 01:10:13 CEST 2010


I think there is a problem in correctly handling residuals
from INQUIRY commands in tgtd using a kernel target
module I'm developing for libfc.  Maybe its correct in
user-level transports but there may need to be a change for
kernel-level transports.

The length requested by the initiator can be exceeded by tgtd,
but this shouldn't lead to an overrun condition for INQUIRY,
as far as I can tell, but in other cases (READ commands) an
overrun condition should be reported.  Is this essentially
correct?  I can't find the wording in SPC3 or FCP4 to
confirm this.

Example:

When an initiator sends an FCP request with INQUIRY and
data length 36, tgtd gives the kernel a buffer of 66
bytes.  If I set the FCP response OVERRUN flag and Residual
count of 30 bytes, however, the initiator (Linux 2.6.34)
retries the INQUIRY 3 times with the same data length and
then gives up on LUN discovery.  If I don't report the
overrun, and just transfer the 36 bytes, then it works.

My problem is that I don't know when to report Overrun and
when not to, but the SCSI layer in tgtd should know that.
My suggestion is that for INQUIRY, and perhaps some other
commands (e.g., REPORT LUNS?) that tgtd (being the SCSI layer on
the target) shouldn't return back a larger buffer than the
target module (kernel) requested.  Can we change tgtd accordingly?

Another alternative would be to explicitly give the residual
value and overflow/underflow indications for the response.

	Thanks,
	Joe

--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the stgt mailing list