RE: Status summary on multiple connections

[Peter Johansson <PJohansson@ACM.org>]

At 11:25 AM 9/29/00, David Robinson wrote:

>I am hearing different stories on the issue of ordering. [...] I thought 
>this problem was already solved at the SCSI layer through the use of 
>ordered commands which in general are not used for disks but always used 
>for tapes?  Since FC will reorder this has to be a solved problem. Would 
>not an initiator talking to a tape target simply set the ordering flag?

Part of the ordering conundrum is solved within SCSI by virtue of the fact 
that SAM recognizes ordered and unordered execution models.

The choice of execution model is usually a matter for the target's designer.

The catch is that in order to enable targets that use an ordered execution 
model, the transport protocol (iSCSI, in this case) has to be able to 
communicate the command ordering to the target. So it will do an 
application little good to declare a task's attribute to be ORDERED if the 
order in which the tasks were created by the initiator is lost en route to 
the target.

This raises the question as to whether or not a particular session (login 
to a LU) should be declared ordered or unordered at the time it is 
instantiated. If there are performance reasons to not care if the commands 
are delivered in order, then perhaps it would be desirable to configure the 
manner of command delivery on a session by session basis.

Whatever you do, make sure that the ability to signal commands to a target 
in the same order they were created at the initiator is a mandatory feature 
of iSCSI.

PS Similar considerations apply to the return of command completion 
information to the initiator IF one wishes to take some short-cuts that 
eliminate the necessity to transmit GOOD status in an ordered environment.




Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org