99-179r2 - DST feature

Gerry_Houlder at notes.seagate.com Gerry_Houlder at notes.seagate.com
Tue Jul 20 11:26:27 PDT 1999

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

More information about the T10 mailing list