SCSI queuing data integrity problem?

SPRENKLE_TODD at tandem.com SPRENKLE_TODD at tandem.com
Tue Jul 26 18:39:00 PDT 1994


SCSI experts,

We're developing host software to use SCSI-2 tagged queuing with disk.
We want to avoid reading/writing the wrong media after a unit
attention condition.

The device doesn't support _extended_ contingent allegiance. So the
contingent allegiance condition resulting from a CHECK CONDITION
status is cleared by a REQUEST SENSE command. [An Automatic Request
Sense feature of the SCSI controller chip is probably used, although I
don't think that affects the concern being expressed here.]

Note that the host won't learn of the unit attention condition until
the REQUEST SENSE command has completed, since the unit attention
condition is indicated in the sense key within the sense data.

Since the contingent allegiance condition will have been cleared by
the time the host learns of the unit attention condition, how do we
avoid continued processing of commands that were already queued in the
device? The unit attention condition could be reporting a change of
media. We certainly don't want commands previously queued in the
device to operate against the changed media.

I see that we can configure the device via MODE SELECT with a QErr bit
of one on the control mode page, resulting in an abort of all
remaining suspended I/O processes after any contingent allegiance
condition. But aborting the queue in this way after every check
condition status seems like a drastic measure. It could affect
performance significantly, depending on the depth of queuing and the
frequency of check condition status. Unit attention conditions, for
which the abort behavior seems most needed, should occur far less
frequently than check condition status.

Is there another solution we're missing? How have other implementors
addressed this problem? Is there a way to use tagged queuing and avoid
potential reading/writing the wrong media but without using a QErr bit
of one?

Thanks,
Todd Sprenkle                                 sprenkle_todd at tandem.com




More information about the T10 mailing list