Re: iscsi: More immediate data than required data

>>>>> "Joel" == Joel Buckley <[email protected]> writes:

 Joel> Barada, The response depends on where 1024 vs. 2048 bytes are
 Joel> encoded...

 Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
 Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 2048, then
 Joel> all 2048 bytes SHALL be read by iSCSI Target and only the first
 Joel> 1024 bytes SHALL be utilized by SCSI Target.

I can't imagine any reason why an initiator would do such a thing, and
I'd prefer to call it an error, but if SCSI requires this sort of
thing to be permitted, then I guess that's how it goes.

 Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
 Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 1024, then
 Joel> all 1024 bytes SHALL be read by iSCSI Target and all1024 bytes
 Joel> SHALL be utilized by SCSI Target.

That's the normal case.

 Joel> In either case, the iSCSI Target SHALL expect the next iSCSI
 Joel> PDU to begin immediately after the last...  So if an additional
 Joel> 1024 bytes of unknown data are appended to a PDU, then results
 Joel> are indeterminate.  The unknown data may be evaluated as
 Joel> another iSCSI PDU or may be seen as a data corruption on the
 Joel> connection.  If the data is seen as a data corruption, then
 Joel> iSCSI ERROR RECOVERY LEVEL protocols SHALL be followed.

That's a third case.  What you're describing is a case where there is
junk in the middle of the iSCSI protocol data stream that isn't
described by any headers, it isn't claimed to be payload.  If so, it
obviously will be seen as another iSCSI PDU header, with whatever
consequences that implies.  Obviously, such a thing cannot ever be
valid -- but depending on the contents of the junk it may or may not
be detected.

   paul


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