Edward A. Gardner
eag at ophidian.com
Sat Sep 29 20:16:07 PDT 2001
The simple answer is that an initiator may not make any assumptions about
the order of requests to the same blocks (by itself or other initiators)
that may be outstanding at the same time. If you care about ordering, an
initiator must wait until previous requests are complete before issuing a
request that references the same block(s).
This assumes that all commands are issued as simple tasks, which is the most
common situation today (one suspects the only situation).
People have suggested more complex schemes in the past, amounting to
exporting some portion of the transfer dependency graph to the target. The
ordered task attribute is one approach to this. None have proved practical
In practice, if a target receives references to the same block from multiple
initiators, it can perform the operations in whatever order it wishes.
There is no "correct" order, all are equally valid. (Again, I'm assuming
all are issued as simple tasks).
Edward A. Gardner eag at ophidian.com
Ophidian Designs 719 593-8866 voice
1262 Hofstead Terrace 719 593-8989 fax
Colorado Springs, CO 80907 719 210-7200 cell
From: Sanjeev Bhagat (TRIPACE/Zoetermeer) <iscsi_t10 at sanjeevbhagat.com>
To: 'IPS Reflector' <ips at ece.cmu.edu>; T10 at t10.org <T10 at t10.org>
Date: Saturday, September 29, 2001 7:03 PM
Subject: iSCSI:Request/Response Ordering
Hello All (T10, IPS),
The SAM-2 specifications makes no assumption about, or places any
requirement on the ordering of requests or responses between tasks or task
management functions received from different SCSI initiator ports.
In this scenario how can a SCSI target make correctly handle the read/write
requests made on same blocks by different intiators at the same time.
More information about the T10