iSCSI:Request/Response Ordering

Edward A. Gardner eag at
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.

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 Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell
-----Original Message-----
From: Sanjeev Bhagat (TRIPACE/Zoetermeer) <iscsi_t10 at>
To: 'IPS Reflector' <ips at>; T10 at <T10 at>
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 mailing list