SCSI queuing data integrity problem?

Gerry Houlder Gerry_Houlder at
Mon Aug 1 17:58:58 PDT 1994

>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.
>          (details deleted)
>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?
If UNIT ATTENTION condition is the only case you are concerned about, these
should be rare occurances. Also, reading the wrong media is relatively
harmless. The data from queued reads could be discarded as it is received with
only a small performance cost. The painful case is queued write commands. There
are several methods for driver design that could help.
1) Are the unexpected Unit Attentions caused by media removal in a removable
media drive? If so, does the drive support the LOCK/UNLOCK media command? By
using this command to lock the media, the media cannot be removed (and replaced
by different media) until the disk manager gives permission. The disk manager
should intercept any requests to write or read from an unlocked disk and return
a "drive not ready" error message. When new media is inserted, the disk manager
must be told so it can lock the new media and check its validity (is it
formatted, etc.). This should eliminate any unexpected Unit Attentions for this
2) Since writes are the real problem, the driver could be designed to not queue
up a bunch of writes. Only one outstanding WRITE command is permitted at a
time. This will hurt the write performance but will gain a lot of data
integrity protection in return.
    A variation on this is to wait for the first command in a long series of
WRITE commands to complete successfully before the rest of the WRITE commands
are issued. This greatly reduces the risk that a Unit Attention (due to media
change) will occur within this sequence of write commands.
    If the drive is used with Write Caching, that complicates things a bit.
Issuing a WRITE command with FUA bit set should cause the drive to write the
data to media before returning GOOD status even if Write Caching is enabled. At
least the first write in a series of writes should have the FUA bit set so that
a GOOD status response will always mean that there were no Unit Attention
conditions present that prevented writing to media. With Write Caching, the
first "GOOD status" merely means that the data was received by the drive. It
may not even be possible to write it to the drive, but the drive controller
doesn't know yet because it hasn't started that process yet.
3) When the driver sees Unit Attention condition, it should abort any
outstanding commands by selecting the drive and sending ABORT message (to abort
all commands) or sending ABORT TAG message (to abort one command). A series of
ABORT TAG sequences can be used to abort several commands. This works for all
cases except queued Write commands that have already taken data from the host
and may already have written some data to the media. This could provide very
good protection if the ABORT message can be sent to the drive within 2
Millisec. after receiving the sense data. This "performance window" is a moving
target, however, so a time fast enough for today's drives may not be fast
enough for tomorrow's.
I hope you see something here that will help your situation. Good Luck!
Gerry Houlder -- Gerry_Houlder at
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  

### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\40.MSG
### Org Date:    08-01-94 07:47:32 AM
### From:        Gerry Houlder at SEAGATE
### To:          scsi @ WichitaKS.NCR.COM @ internet
### Subject:     Re: SCSI queuing data integrity problem?
### Attachments: none

More information about the T10 mailing list