99-179r2 - DST feature

Jeffrey L Williams Jeffrey.L.Williams at wdc.com
Tue Jul 20 16:14:43 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Jeffrey L Williams <Jeffrey.L.Williams at wdc.com>
*

First, STPI was removed.  

The progress indicator works exactly as it does for the format immediate
command.  If there is sense data pending for a check condition, that data
is returned.  If there is none, then the sense data returned indicates NOT
READY, or NO SENSE, the sksv bit is set and the progress indicator
indicates the progress.  There is always an issue with more than one
non-cooperative clients on a single initiator ID.  If they cannot
cooperate, then none of this works (and neither would the format progress
indicator).

If you have two clients that insist on stepping on each other, then they
will and nothing we can do will fix the problem.  Consider cases where a
second, non-cooperative client issues a read command following the CHECK
CONDITION for the first client.  The read command will clear the sense
data also.  We do not protect an initiator and clients from this....

I vote for "do nothing" since I think it works as is.  

Regards,
Jeff

Jeffrey L. Williams
Senior Staff Engineer
Western Digital Rochester - Enterprise Storage Group
Office: (507) 286-7589
Fax: (507) 536-8089
Pager: (888) 858-PAGE   ID: 120826
e-mail: Jeffrey.L.Williams at wdc.com


----------
From:
	Gerry_Houlder at notes.seagate.com[SMTP:Gerry_Houlder at notes.seagate.com]
Sent: 	Tuesday, July 20, 1999 11:26 AM
To: 	t10 at symbios.com
Subject: 	99-179r2 - DST feature

* From the T10 Reflector (t10 at symbios.com), posted by:
* Gerry_Houlder at notes.seagate.com
*
During discussion of the target response to a REQUEST SENSE command with
STPI bit set, I didn't get an acceptable answer for this situation:

(1) Client 1 on initiator A is doing a stream of read and write commands
to
a drive.
(2) Client 2 on initiator A starts a background DST on the same drive. It
periodically issues REQUEST SENSE with STPI bit set to poll for DST
completion.
(3) One of client 1's commands ends with CHECK status.
(4) Client 2 happens to send REQUEST SENSE with STPI bit set. As described
in the meeting, this will return DST progress and clear the CA for Client
1.
(5) Client 1 driver tries to retrieve sense bytes for its CHECK CONDITION
and gets all zeros (because sense was cleared by client 2).

Note that it isn't possible to return both sets of sense bytes in one
REQUEST SENSE command unless we create some new rules (I am not ready to
suggest this as an answer). I suspect that the driver for client 1 is
going
to be upset that all zeros sense data was returned for its problem. This
would definitely be logged as a severe system error and the driver
wouldn't
know whether recovery should be performed. Perhaps someone that does
driver
software could explain a typical response for this situation.

There are some possibilities here:
(a) The host community thinks this is not a problem, nothing needs to be
done.
(b) We could define REQUEST SENSE with STPI set to not clear sense bytes
for a CA.
(c) We could require a REQUEST SENSE with STPI to be queued (blocked until
the CA is cleared) if a CA exists.

I think (b) is easier to do than (c), but I would like to hear from the
host community to decide if this is really a problem.


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


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





More information about the T10 mailing list