gmane.ietf.ips

Re: Data Out residual overflow/underflow handling

Paul Hughes — 2012-09-21T15:45:16

Thanks for the detailed response Fred.  I will post this question to the
T10 reflector to see what they have to say, but thought I'd start here.

One follow up question:  If the initiator didn't send any immediate data
(the iSCSI Command Request PDU EDTL=512, but the data segment length is 0
and the Final bit is set), would the target have the same options?  I
believe the only difference would be the Sense Key that is reported
(Illegal Request if no immediate data was transferred, and Aborted Command
if immediate data was transferred).  I expect the residual reporting would
remain the same regardless of whether any data was transferred or not,
correct?

Thanks,
Paul



On Fri, Sep 21, 2012 at 8:00 AM, Knight, Frederick <
Frederick.Knight< at >netapp.com> wrote:

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

Re: Data Out residual overflow/underflow handling

Knight, Frederick — 2012-09-21T14:00:21

You have a couple of choices.

For example, SBC makes several statements about non-deterministic outcomes such as:

The device server may terminate the command before processing or after the device server has transferred some or all of the data. (walking off the end of the device)

The degree that the medium is altered by this command is vendor specific. (The format command)

But those aren't directly related.  However, as you mention, FCP provides the following 3 choice:

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

Data Out residual overflow/underflow handling

Paul Hughes — 2012-09-21T03:21:32

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
handlin

about iSCSI TEXT negotiation

yushang — 2012-03-30T17:44:17

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

Re: data exceeds MaxBurstLength

2012-03-29T15:30:20

It's covered by the general rules on protocol errors.  A reasonable reaction would be for the receiving node to close the connection (and probably log the protocol error using whatever logging machinery it has available).

paul

-----Original Message-----
From: ips-bounces< at >ietf.org [mailto:ips-bounces< at >ietf.org] On Behalf Of yushang
Sent: Thursday, March 29, 2012 11:17 AM
To: ips< at >ietf.org
Subject: [Ips] 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
_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

data exceeds MaxBurstLength

yushang — 2012-03-29T15:17:24

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

Re: iSCSI WRITE (10)

Sanjay Goyal — 2011-02-14T03:50:27

Response should be sent once, after all the write data ( I assume it is
unsolicited data) is received.

I -> T PDU 0x01 (scsi request), opcode 0x2a (WRITE 10)
I -> T PDU 0x05 (data out)
I -> T PDU 0x05 (data out)
...
T -> I PDU 0x21 (scsi response, for each data out)


-----Original Message-----
From: ips-bounces< at >ietf.org [mailto:ips-bounces< at >ietf.org] On Behalf Of
folkert
Sent: Wednesday, February 09, 2011 11:08 PM
To: ips< at >ietf.org
Subject: Re: [Ips] iSCSI WRITE (10)


Let me elaborate:

I -> T PDU 0x01 (scsi request), opcode 0x2a (WRITE 10)
T -> I PDU 0x21 (scsi response)
more data follows, so
I -> T PDU 0x05 (data out)
T -> I PDU 0x21 (scsi response, for each data out)


Folkert van Heusden

Re: iSCSI WRITE (10)

folkert — 2011-02-09T17:38:02

Let me elaborate:

I -> T PDU 0x01 (scsi request), opcode 0x2a (WRITE 10)
T -> I PDU 0x21 (scsi response)
more data follows, so
I -> T PDU 0x05 (data out)
T -> I PDU 0x21 (scsi response, for each data out)


Folkert van Heusden

iSCSI WRITE (10)

folkert — 2011-02-09T17:18:28

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

SCSI inquire command & iscsi wrapping

folkert — 2011-02-02T14:13:40

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

Re: this list

Ralph Weber — 2011-01-24T17:12:49

Not all CHECK CONDITIONs are created equal.

When the Sense Key is Unit Attention, you are receiving the only
flavor of asynchronous event notification that modern SCSI supports.

If you retry the READ CAPACITY command, it should work.

ON THE OTHER HAND

You are well advised to pay heed to asynchronous event notifications
such as the one shown below. They ALWAYS tell you something unusual
has happened in the device.

In this particular case, a power cycle (or equivalent, an iSCSI login
perhaps) has happened since the last time you received status for
some other SCSI command.

If your driver's work queue has any outstanding commands that are
waiting for status, that status will never come.

If you previously used a MODE SELECT command to change the mode
parameters, you might want to check to see if they are still in
effect (frequently the changes will be gone).

In a nutshell, all the saved state of the device is suspect.

All the best,

.Ralph

On 1/24/2011 10:27 AM, folkert wrote:
_________________________

Re: this list

folkert — 2011-01-24T16:27:09

Hi,

The CDB I send is:
SCSI CDB Read Capacity(10)
    [LUN: 0x0000]
    [Command Set:Direct Access Device (0x00) (Using default commandset)]
    [Response in: 12]
    Opcode: Read Capacity(10) (0x25)
    Logical Block Address: 0
    PMI Flags: 0x00
        .... ...0 = PMI: Pmi is CLEAR
    Vendor Unique = 0, NACA = 0, Link = 0

(0x25 for the first byte, the rest 0x00)

the reply is:
SCSI: SNS Info
    [LUN: 0x0000]
    Valid: 0
    .111 0000 = SNS Error Type: Current Error (0x70)
    Filemark: 0, EOM: 0, ILI: 0
    .... 0110 = Sense Key: Unit Attention (0x06)
    Sense Info: 0x00000000
    Additional Sense Length: 10
    Command-Specific Information: 00000000
    Additional Sense Code+Qualifier: Power On, Reset, Or Bus Device Reset Occurred (0x2900)
    Field Replaceable Unit Code: 0x00
    0... .... = SKSV: False
    Sense Key Specific: 000000

in hex:
70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 00 00


On Mon, Jan 24, 2011 at 11:09:30AM -0500, Knight, Frederick wrote:


Folkert van Heusden

Re: this list

Knight, Frederick — 2011-01-24T16:09:30

On the other hand, it depends on what CHECK CONDITION you are getting.

Can you supply the full CDB and full response (all sense data including) - status, sense key, ASC/ASCQ, data (if any).

If you are sending a badly formed CDB, they the device is perfectly within its rights to return CHECK CONDITION - but when it does, it should also return more info about what is wrong (and that will be down in the detailed bits of the returned sense data).

Invalid OP Code is not valid for a disk to return (as per previous comments), but INVALID FIELD IN CDB means you made a mistake.

Fred Knight

-----Original Message-----
From: david.black< at >emc.com [mailto:david.black< at >emc.com] 
Sent: Monday, January 24, 2011 10:39 AM
To: folkert< at >vanheusden.com; ips< at >ietf.org
Subject: Re: [Ips] this list

That's actually more of a generic SCSI question than an iSCSI question, but anyhow ...

... if READ CAPACITY (10) doesn't work, try READ CAPACITY (16) [opcode 0x9E, service action 0x10].

OTOH, if READ CAPACITY (10) results in a Check

Re: this list

Knight, Frederick — 2011-01-24T15:58:32

The list t10< at >t10.org is good for generic SCSI questions like this.

Basically, if it's a disk, you've got a device that is violating SCSI
standards.  That command is a mandatory (a command the device MUST
support) for a block/disk device.  If the device is not a disk, then
different rules would apply.

Fred Knight

-----Original Message-----
From: folkert [mailto:folkert< at >vanheusden.com] 
Sent: Monday, January 24, 2011 8:30 AM
To: ips< at >ietf.org
Subject: [Ips] 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

Re: this list

2011-01-24T15:39:05

That's actually more of a generic SCSI question than an iSCSI question, but anyhow ...

... if READ CAPACITY (10) doesn't work, try READ CAPACITY (16) [opcode 0x9E, service action 0x10].

OTOH, if READ CAPACITY (10) results in a Check Condition for invalid opcode, the target that issued that CC does not comply with the SCSI standards, as support for READ CAPACITY (10) is mandatory for block devices in both the SBC-2 standard and all drafts of the in-progress SBC-3 standard.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black< at >emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

this list

folkert — 2011-01-24T13:30:21

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

Contribution to ISCSI in opensource

mandar sawant — 2010-06-18T06:11:32

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

Re: Data Segment Padding

2009-10-09T06:46:58

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

Data Segment Padding

yushang — 2009-10-09T03:33:52

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

Re: Data-In ExpDataSN

2009-09-25T14:43:44

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips

Data-In ExpDataSN

yushang — 2009-09-25T06:30:46

_______________________________________________
Ips mailing list
Ips< at >ietf.org
https://www.ietf.org/mailman/listinfo/ips