headers
Paul Hughes | 21 Sep 2012 05:21
Favicon

Data Out residual overflow/underflow handling

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



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 2 comments |
headers
yushang | 30 Mar 2012 19:44
Picon

about iSCSI TEXT negotiation

Hi dear all,
Please think about the following sequence
I->TEXT,C=1,F=0
T->TEXT,C=x,F=0,DataSegmentLength=0
What is the valid target response ?
Does the value of x matter ?
or just DataSegmentLength=0 is enough ?
Many thanks .
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 0 comments |
headers
yushang | 29 Mar 2012 17:17
Picon

data exceeds MaxBurstLength

Hi dear all,
If the transmitter (initiator or target) transfer some data exceeds the value
MaxBurstLength specified . What shold happen ? It seems rfc3720 do
not provide a clause for this situation . Thanks in advance .
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 1 comment |
headers
folkert | 9 Feb 2011 18:18
Gravatar

iSCSI WRITE (10)

Hi,

Ok I'm a lot further: the whole discovery handshake (including mode
sense, inquiries and what not) works find. Small reads/writes work too
(the ones with data in the pdu message).

Something which is not entirely clear from the RFC is the following:
- an initiator sends a 0x05 PDU (data-out) with data to be stored on
  disk.
  after processing, the target should send back a 0x21 PDU (scsi
  response). is that correct?

Folkert van Heusden

--

-- 
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 2 comments |
headers
folkert | 2 Feb 2011 15:13
Gravatar

SCSI inquire command & iscsi wrapping

Hi,

I'm struggling to get scsi 0x12 command working in my iSCSI target
(which will be an opensource java iSCSI target by the way).

I follow the procedure as described at
http://en.wikipedia.org/wiki/SCSI_Inquiry_Command

If I understand it correctly this is what happens:
Now, I receive an PDU with opcode 0x01 (SCSI command). In it, there's
the CDB with byte 3 and 4 telling how much extra data (apart from the
regular 16 CDB in the PDU) may be send by the target.
So as a target, let's say cdb byte 3+4 tell me i can send 'x' bytes.
So in the CDB space in the PDU I put a CDB with opcode 12 and byte 3+4
telling how many bytes I want to send.
Then, of the next 36 bytes I would want to send (I don't have any vendor
specific data), I can add 'x' bytes after the PDU with byte 4 set to
MIN(x, 36) - 4.

My question now is: am I right?

Folkert van Heusden

--

-- 
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 0 comments |
headers
folkert | 24 Jan 2011 14:30
Gravatar

this list

Hi,

Is this list available for generic iSCSI questions?

If so: some (linux iscsi target and window iStorageSErver) respond with
valid data to Read Capacity(10) SCSI 0x25 command while for example
nexenta store (an opensolaris system) responds with Check Condition.
So I guess this is not the common way of determing the sector size and
size of the device.
Which command should I use for this?
Thanks.

Folkert van Heusden

--

-- 
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 5 comments |
headers
mandar sawant | 18 Jun 2010 08:11
Picon

Contribution to ISCSI in opensource


Hello,
 
I have been working on iscsi and Filesystems for some period of time.
I would like to contribute to opensource for ISCSI/Filesystems.
How can do that?

Thanks & Regards,
Mandar
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 0 comments |
headers
yushang | 9 Oct 2009 05:33
Picon

Data Segment Padding

Hi , is it possible to send the middle part of a sequence of DATA-OUT with data segment padding to 4 bytes boundary ? Many thanks.

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 1 comment |
headers
yushang | 25 Sep 2009 08:30
Picon

Data-In ExpDataSN

Dear all , RFC 3720 says that Data-In/R2T PDU number is acknowledged by ExpDataSN filed of SCSI Response . But if a target choose to send a Data-In PDU with S bit set instead of a SCSI Response . Where to get the ExpDataSN ? There is no such a field in Data-In PDU. Many thanks.

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 1 comment |
headers
yushang | 22 Sep 2009 06:34
Picon

iSCSI RW Command

Dear all , as mentioned above , what kind of SCSI command can be classfied as RW command in iSCSI sense ? For an example ? Thanks in advance

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 1 comment |
headers
Mike Christie | 11 Aug 2009 22:56
Picon
Favicon

lun reset and r2t error handling

Hi,

For a single connection session with ERL=0 and without FastAbort, if the 
initiator has sent a lun reset task management function and the target 
has sent a R2T, is it ok for the target to send a task management 
response with Function Complete, before the initiator has sent the 
data-out pdus for the R2T? It looks like the reason the target will do 
this is due to a internal target timeout (target did not get the 
data-outs within some timeout period).

If the target does return the task management function with Function 
Complete, should the initiator continue to respond to the R2Ts?

And one other question. In section 10.5.1, we have:

    The issuing initiator SHOULD however terminate (i.e., by setting the
    F-bit to 1) these response sequences as quickly as possible.

Does this mean if we have sent a lun reset, and the target has sent a 
R2T, should we be setting the F-bit in the continued data-out PDU so as 
to end the transfer, even though actual data transfer has not been 
completed entirely?

What if we do send all the data like normal, should that still be ok?
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Permalink | Reply | 3 comments |

Gmane