task states?

Elliott, Robert Robert.Elliott at COMPAQ.com
Mon Feb 11 17:50:21 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at COMPAQ.com>
*
Comments inline...

Mallikarjun Chadalapaka wrote:
> > I think it's correct.
> > 
> > The task is made of multiple commands.  The task itself is what goes
> > through those states, not each individual command.  If you 
> get a CA all
> > the linked commands are blocked as a set.
> 
> Okay, that's the other possibility I suspected and which SAM-2's 
> current language upon closer reading seems to confirm, but here's
> my reasoning for thinking that each of the commands goes through
> the same state transitions.
> 
> - I assumed a device server may need to address resource constraints 
>   before a task is transitioned out of the Dormant state.  If this
>   is a reasonable interpretation of SAM-2's language, then the same
>   constraints would need to be faced and addressed for each of the
>   commands in a task.  It sounds like SAM-2 would rather suggest the
>   constraints be addressed in the Enabled state for linked commands...
>
> - I reasoned that if a Reservation on an LU is obtained by 
>   one initiator when a second initiator is half way through its 
>   task with linked commands, the next (linked) command from the 
>   second initiator should get a RESERVATION CONFLICT - thus implying 
>   that each command goes through the transitions.
>   If it were the task going through the transitions, (since it's
already
>   transitioned to the Enabled state,) none of the following linked
>   commands would see a reservation conflict even though the device 
>   server by then is reserved for exclusive use by the first 
>   initiator.  It seems to be that the latter behavior is 
>   currently intended....

More good reasons to get rid of linked commands :-)

I think once the set of linked commands has been enabled,
reservation conflicts are not supposed to occur. SPC-2/3's
wording on reservation conflict checking needs modification.  
It is trying to allow write commands to do harmless activity
(e.g. prefetch) before reporting the reservation conflict,
but prevent non-write commands from doing anything.  SAM-2
already covers that concept when describing the enabled
task state, so eliminating that distinction may help.

SPC-3 5.5.1:
"A command that does not explicitly write the medium shall be
checked for reservation conflicts before the command enters
the enabled task state for the first time. Once the command
has entered the enabled task state, it shall not be terminated
with a RESERVATION CONFLICT due to a subsequent reservation.

A command that explicitly writes the medium shall be checked
for reservation conflicts before the device server modifies
the medium or cache as a result of the command. Once the
command has modified the medium, it shall not be terminated
with a RESERVATION CONFLICT due to a subsequent reservation."

SAM-2 7.4.2 Enabled task state:
"...Although, before entering this state for the first
time, the task may perform other activities visible to
lower layers - such as pre-fetching data to be written
to the media - this activity shall not result in a
detectable change in state as perceived by an
application client."

SPC-3 possible change:
An unlinked command shall be checked for reservation
conflicts before the task containing that command
enters the enabled task state for the first time. The
first command in a group of linked commands shall be
checked for reservation conflicts before the task
containing that command enters the enabled task state
for the first time. Once a task has entered the enabled
task state, the command or commands comprising that
task shall not be terminated with a
RESERVATION CONFLICT due to a subsequent reservation. 

---
Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com


*
* 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