ordering across I_Ts

Elliott, Robert (Server Storage) Elliott at hp.com
Tue Dec 20 11:29:17 PST 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
[Pulling out question #3...]

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Gerry.Houlder at seagate.com
> Sent: Monday, December 19, 2005 9:49 AM
> To: Frederick.Knight at netapp.com
> Cc: t10 at t10.org
> Subject: Re: TMF, ordering across I_Ts, and ALUA questions
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> My responses added as GAH.

> From: "Knight, Frederick" <Frederick.Knight @netapp.com>

> To: <t10 at t10.org>          
> Subject: TMF, ordering across I_Ts, and ALUA questions              
> Date: 12/16/2005 01:51 PM

> 
> 3) Relative ordering of ordered and head of queue tagged commands
> 
>    Summary
>    -------
>    When a TST=000b target receives a task with the Ordered or
>    Head_Of_Queue task tag on an I_T_L Nexus A, do the ordering
>    requirements apply to tasks from other I_T_L Nexuses?
> 
> GAH: No, they do not.

I agree about the L part, but since the example below talks
just about I_T nexuses, I assume the question was intended
to be "other I_T nexuses."

sam4r04 section 8.2 includes these definitions:
"All older tasks ended:
If the TST field in the Control mode page (see SPC-3) equals 
000b, all tasks received <<on all I_T nexuses>> and accepted
earlier in time than the referenced task have ended.

All head of queue and older ordered tasks ended:
If the TST field equals 000b, all the following tasks
received <<on all I_T nexuses>> have ended:
  a) All head of queue tasks; and
  b) All ordered tasks accepted earlier in time than the 
     referenced task."

Section 8.6.3 uses them to define handling of ordered tasks:
"The task shall not enter the enabled task state until 
all head of queue tasks and all older tasks in the task set 
have ended (see 8.4)."

So, given the words highlighted in << >>, an ordered task has 
to wait on tasks received on all I_T nexuses (within the 
same logical unit).

>    Details
>    -------
>    Section 8 of SAM3R14 describes task set management, including
>    relative ordering of tasks.  For example:
> 
>      - Tasks with the Ordered Task Attribute cannot enter the ENABLED
>        state until all in-progress head of queue and all older tasks
>        in the task set have completed (section 8.6.3)
>      - Tasks with the Simple Task Attribute cannot enter the ENABLED
>        state until all head of queue tasks and older ordered
>        tasks have completed (section 8.6.2)
>      - etc.
> 
>    If the target maintains one task set per LUN for all initiator
>    ports (Control mode page TST = 000b), then the task set may
>    include tasks submitted by multiple initiators, over multiple
>    I_T nexuses.
> 
>    Since the ordering semantics described in SAM3R14 section 8 are
>    described in terms of the task set, this implies an ordering
>    constraint on commands and responses across different I_T
>    nexuses.
> 
>    But section 4.6.3 of SAM3R14 states the following:
> 
>      "The SCSI architecture model makes no assumption about and places
>       no requirement on the ordering of requests or responses for
>       different I_T nexuses."

That relates to the ordering between sending and receiving SCSI 
ports (e.g. over the FC, SAS, iSCSI, etc. interface).  It doesn't 
override any rules for a device server.  However, if a device
server sends a first response out target port A and then sends a 
second response out target port B, it means the application client 
may receive the second response before the first.

>    So, consider the case of two I_T Nexuses submitting IO requests
>    to the same LUN on a TST=000b target.  Assume the initiators
>    submit the following commands in the following order, and also
>    assume that the target receives the commands in the same order:
> 
>       Nexus A submits simple command A1
>       Nexus B submits simple command B1
>       Nexus B submits simple command B2
>       Target moves all of A1, B1, and B2 to the Enabled state
>         and starts work on them
>       Nexus A submits ordered command A2
> 
>    When is the target allowed to begin processing A2:
> 
>    - After completion of A1 only?
>    - Or after completion of A1, B1, and B2?
> 
> GAH: A2 can begin processing as soon as A1 completes.

I think it has to wait.

>    Here's another case:
> 
>       Nexus A submits ordered command A3
>       Target moves A3 to the Enabled state and starts work on it
>       Nexus B submits simple command B3
>       Nexus B submits simple command B4
> 
>    Does the presence in the task set of A3 prevent the target from
>    beginning work on B3?
> 
> GAH: The T10 rules would allow B3 and/or B4 to be processed ahead
>      of command A3. That doesn't mean that a target is required to do
>      that ordering, however. Thats what "no requirement on ordering
>      between commands from different ports" means.

I think it has to wait.

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





More information about the T10 mailing list