Re: iSCSI & Linked Commands

["Nelson Nahum" <nnahum@store-age.com>]

The Skip Read and Skip Write commands used by the AS400 for skip sectors
already in cache must use linked commands.
I cannot see how command queuing can be used instead, as the data of the
first command is used as the parameter for the subsequent.
(need to ensure that both commands are one after the other)

Nelson
----- Original Message -----
From: Robert Snively <rsnively@Brocade.COM>
To: <julian_satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Monday, April 23, 2001 4:46 PM
Subject: RE: iSCSI & Linked Commands


> Folks,
>
> There are no implementation problems with linked commands other than
> the fact that nobody has really found a good use for them outside
> a few specialized environments.  It is for that reason that they
> are relatively rarely called upon, but strongly defended by their
> few users.
>
> This thread has created a significant amount of unclarity.
>
> First:
>
> A task includes all commands executed in a single
> link.  It has the same Exchange identifier for all
> steps in executing a command.  That takes care of the
> concerns expressed by Santosh.
>
> Second:
>
> A set of linked commands is executed in order, by
> definition, but their ordering with respect to other
> tasks from the same or other initiators is not defined
> except through the ordinary command ordering stuff.
> The task ordering applies to the entire task, although
> this is not as explicitly defined in SAM as would be
> desirable.  This eliminates them as being tremendously
> useful in ordered execution.
>
> Third:
>
> I am not aware of any usage of commands using relative
> addressing.  They are denigrated in all profiles.  They
> are a historic anomaly dating back to when SCSI was thought
> of as a total replacement for the IBM OEM channel.
> Relative addressing is defined for disk devices only,
> not sequential devices.  Sequential devices use the
> more traditional space, skip, and locate commands.
> This eliminates relative addressing for linked commands as
> being useful to sequential devices.
>
> Fourth:
>
> Stale PDUs are a fact of life in any stream of data that
> is not acknowledged and sequenced on a PDU by PDU basis.
> Both Fibre Channel and iSCSI have to deal with that.
> Fibre Channel has a function called "recovery qualifier"
> that automatically discards stale PDUs.  It has an additional
> function called R_A_TOV which guarantees that stale PDUs
> will not appear later than a certain time.  With those two
> mechanisms, stale PDUs become a non-problem.  In FCP,
> an additional mechanism is provided to handle the stale
> PDUs created by Abort Task actions.
>
> One way or another, iSCSI will have to deal with the same
> problem.
>
> Notes of possible interest:
>
> Command linking is an anachronism.  It has been used by a few
> devices that think of themselves as having IBM OEM channel-like
> characteristics, where a list of commands is the normal I/O
> execution unit.  It was also used by Sun Microsystems in early
> SCSI implementations that used software selection algorithms that
> were so high in overhead that command linking provided improved
> performance.  Aside from those cases that have been listed here
> (AS400 and some Unisys systems), command linking is not in modern
> use as far as I know.  Command queuing and buffering have provided
> performance improvements that are so notable that command linking
> has fallen aside.