Data Out residual overflow/underflow handling

--===============4333619166579011772==
Content-Type: multipart/alternative; boundary=f46d043894a9879eae04ca2dbc33

--f46d043894a9879eae04ca2dbc33
Content-Type: text/plain; charset=ISO-8859-1

Not sure if this is the best place to ask, but here goes...

How should an iSCSI target (SCSI direct-access block device) handle the
following scenario:

An initiator issues an iSCSI Command Request PDU containing a SCSI Write
CDB with a transfer length of 1 block.  The iSCSI Command Request PDU has
an Expected Data Transfer Length of 512 bytes, a Data Segment Length of 512
bytes (immediate data), and the Final flag is set.  This would be a
perfectly normal single block write, except that the target's logical unit
is formatted with 4096-byte block size.  So it appears the initiator is
confused and sending a single 512-byte block write to a logical unit that
is formatted to 4KB block size.

Here are my thoughts:

1) The target could write the 512 bytes of immediate data plus 3584 bytes
(4096 minus 512) of whatever it wants to the media, and then send an iSCSI
Command Response PDU with SCSI status of Good and reporting an Overflow
with a residual count of 3584.  This seems to be the most correct way of
handling this scenario, but it seems dangerous to allow an apparently
confused initiator to essentially corrupt data on the logical unit.

2) The target could send an iSCSI Command Response PDU with SCSI status of
Check Condition, with sense data of Aborted Command, Invalid Field in
Command Information Unit (0x0E03).  This sense code is apparently intended
for FCP (I found it mentioned in FCP-4) but it seems appropriate in this
case.  Assuming the target can fail the SCSI Write command this way (or
some other way), should the target also report an Underflow with a residual
count of 512?

Are there any other alternatives?

Thanks,
Paul

--f46d043894a9879eae04ca2dbc33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Not sure if this is the best place to ask, but here goes...<div><br></div><=
div>How should an iSCSI target (SCSI direct-access block device) handle the=
 following scenario:</div><div><br></div><div>An initiator issues an iSCSI =
Command Request PDU containing a SCSI Write CDB with a transfer length of 1=
 block. =A0The iSCSI Command Request PDU has an Expected Data Transfer Leng=
th of 512 bytes, a Data Segment Length of 512 bytes (immediate data), and t=
he Final flag is set. =A0This would be a perfectly normal single block writ=
e, except that the target&#39;s logical unit is formatted with 4096-byte bl=
ock size. =A0So it appears the initiator is confused and sending a single 5=
12-byte block write to a logical unit that is formatted to 4KB block size.<=
/div>

<div><br></div><div>Here are my thoughts:</div><div><br></div><div>1) The t=
arget could write the 512 bytes of immediate data plus 3584 bytes (4096 min=
us 512) of whatever it wants to the media, and then send an iSCSI Command R=
esponse PDU with SCSI status of Good and reporting an Overflow with a resid=
ual count of 3584. =A0This seems to be the most correct way of handling thi=
s scenario, but it seems dangerous to allow an apparently confused initiato=
r to essentially corrupt data on the logical unit.</div>
<div><br></div><div>2) The target could send an iSCSI=A0Command Response PD=
U with SCSI status of Check Condition, with sense data of Aborted Command, =
Invalid Field in Command Information Unit (0x0E03). =A0This sense code is a=
pparently intended for FCP (I found it mentioned in FCP-4) but it seems app=
ropriate in this case. =A0Assuming the target can fail the SCSI Write comma=
nd this way (or some other way), should the target also report an Underflow=
 with a residual count of 512?</div>

<div><br></div><div>Are there any other alternatives?</div><div><br></div><=
div>Thanks,</div><div>Paul</div><div><br></div><div><br></div><div><br></di=
v>

--f46d043894a9879eae04ca2dbc33--

--===============4333619166579011772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ips

--===============4333619166579011772==--