Interesting "uninterrupted sequence" question

Gerry.Houlder at Gerry.Houlder at
Fri May 22 12:56:04 PDT 2009

* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
I think SCSI promises a little more than what you describe. A SCSI device
might choose to reorder commands 1 and 2, but it shall complete each
command before doing an overlapping command. My customers would tell me I
have a broken product if they sent two consequetive writes (0 and 1), both
completed with GOOD status,  and some blocks had pattern 0 and some had
pattern 1.
	     <Frederick.Knight						To>	       <t10 at>			   
	     Sent by:							cc 
	     owner-t10 at						   
	     No Phone Info					   Subject 
	     Available		       Interesting "uninterrupted	   
				       sequence" question		   
	     05/22/2009 11:34						   
* From the T10 Reflector (t10 at, posted by:
* "Knight, Frederick" <Frederick.Knight at>
It is well understood that multiple concurrent overlapping commands can
interfere with each other.  For example, if I have 2 successful
concurrent SIMPLE tagged WRITE commands as follows:
1) WRITE 0s to LBA 1,2,3
2) WRITE 1s to LBA 1,2,3
There is no guarantee what will be in LBAs 1,2,3.  It could be 0s in
some of those LBAs, or 1s in some of those LBAs.  The device could
legally do the following:
WRITE 0s to LBA 1,3
WRITE 1s to LBA 1,3
seek to get to LBA 2 (maybe LBA 2 got revectored)
WRITE 1s to LBA 2
WRITE 0s to LBA 2
So a READ of LBA 1,2,3 would not get all 0s or all 1s, it would get
whatever was the result of the interaction of those 2 overlapping WRITE
commands.  It is the responsibility of the application client to used
ORDERED commands or other means to create the consistency it needs.
Now, along comes ORWRITE, XDWRITE, XPWRITE, and other commands with an
"uninterruptable series of actions".
It seems clear that these "uninterruptable" actions can be ABORTed, so
in fact, some interruptions can occur.	I interpret the uninterruptable
nature to relate to the above case (multiple concurrent overlapping
commands that are also required to be uninterruptable).
So, change the above case to ORWRITEs (with an initial state of all
zeros in LBAs 1,2,3):
1) ORWRITE 1 into each LBA 1,2,3
2) ORWRITE 2 into each LBA 1,2,3
Because both commands are "uninterruptable" then I know, that when both
commmands complete, and I READ LBA 1,2,3 each LBA will contain 3 (1 and
2 will each be "OR"ed into each block).  I will not find the value 1 or
2 in any of those LBAs.  Because of the uninterruptable series of
actions, the result is as if the commands had been ORDERED commands.
So, next, what happens when I MIX overlapping concurrent uninterruptable
with interruptable commands?  Consider (again SIMPLE tagged, and an
initial state of all zeros in LBAs 1,2,3):
1) READ LBA 1,2,3 (transfer data for LBA 1,3)
2) ORWRITE 1 into each LBA 1,2,3
3) (transfer data for LBA 2 and complete READ command)
I assume since the READ is not required to be uninterruptable, it
operates just like the first case.  While the ORWRITE is executing, the
READ can continue to execute, so the READ could return some of those
LBAs with 0 in them, and some of those LBAs with 1 in them.
The consistency of an uninterrupted series of actions is only protected
/ guaranteed in relation to the actions of other overlapping
uninterrupted series of actions.
Is this generally agreed?  If not, this may become a July discussion
	     Fred Knight
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list