RE: iSCSI & Linked Commands

["Douglas Otis" <dotis@sanlight.net>]

Santosh,

Linked commands typically employ a feature that allows relative addressing
for sequential devices.  Link bits are still present within the CDB even for
fibre channel.  As only one link command is ever seen on the network at any
point in time, identify the most recent command related to a task and then
use this information to associate the Abort Task command possibly issued
when the ULP times out.  This assumes that Abort Task would be the command
used in this event and that the backup application is able to recover from
such.

For your scheme to work, log all command's connection allegiance, examine
all CDBs to determine their nature, and identify the related task based on
the content of a management command.  You are suggesting that the connection
will be flushed by your technique, but if not, tear down the connection?
Without any acknowledgement as to what was delivered into the SCSI layer,
this forces a wait for the ULP to timeout on each command.  Potentially this
invites a large list of timeouts to stumble over before recovery while each
timeout may be met with a management command.  One wonders if you have saved
any effort.  This is compared to checking the sequence of commands at the
receiver which also provides acknowledgement.  This means there is no extra
effort to ensure sequential delivery and a problem can be detected and
overcome without involving the ULP.

A result of not having any acknowledgement within the iSCSI transport would
be all problems are determined by timeouts within the ULP.  Each problem is
met with uncertainty of cause.  There would only be one command to flush per
such timeout however.  I was just trying to correct the language you used
with respect to command and not task allegiance.  You have however failed to
continue the operation of the sequential device based on a network problem.
In addition, you must ensure that the driver notices the intent of the
management command and finds the correct connection to send this command.
If this connector is indeed unplugged, then this command as well as the one
you are attempting to abort will timeout.  After two ULP timeouts, a
connection tear down will then create many more such events even if the
problem is not with the network.  Check by pinging first?  How long do you
wait for a ping to respond?

Without management being serialized, you could not be sure of their
placement relative to other connections.  All connections would need to stop
until this management command is acknowledged by the SCSI device and even
then these pending commands on other connections may not have already
arrived.  The first timeout caused some application to screech to a halt and
now the entire system will be required to wait for this recovery.  Should
this problem happen again, there will be uncertainty as to whether it is a
connection problem or a device problem.  A ping down the connection in
question may reveal a problem after an additional timeout. You have removed
communication with the sequencer with the exception of "rare" sequential
commands but recovery from a connection falter looks difficult, slow and
highly dependent upon the ULP being well written for this iSCSI environment.

Doug

> Charles Monia wrote:
>
> > > Mark has already replied to your question on why linked commands won't
> > > work given today's implementations. In most cases, the initiator task
> > > tag is either generated in the HBA driver or in the HBA firmware.
> >
> > The fact that some adapter implementations on some interconnects may not
> > support linked commands does not grant a license to delete the
> capability
> > from the protocol specification.
>
> Charles,
>
> I was'nt saying that iSCSI must not support linked commands. See my
> comment on this :
>
> > I agree that there is no need to say linked commands are unsupported
> > since this is a ULP feature and support or lack thereof is decided at
> > the initiator and target ULPs.
>
> What I did say was that several/most implementations perform task tag
> initialization at the LLP or further below rendering this feature
> un-usable in several cases.
>
> The more interesting question is :
> Is there any particular reason connection allegiance would rather be
> enforced per command than per task ? (if linked commands are un-used,
> this is a moot question....). If it were enforced per task, then, an
> Abort Task would effectively flush all stale PDUs of that task ensuring
> no stale PDUs in the network upon I/O termination at the initiator.
>
> - Santosh