Subject: Re: iSCSI & Linked Commands

From: [email-masked]
Date: Thu, 19 Apr 2001 11:18:13 +0200

According to your logic no FCP implementation can use linked commands?

Is this true for all OS's?  Is it a verified fact or foloklor?   Is it so
also for the new MS StorPort driver?

JUlo

Santosh Rao <[email-masked]> on 18/04/2001 20:07:39

Please respond to Santosh Rao <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI & Linked Commands

[email-masked] wrote:
>
> Santosh,
>
> iSCSI HBAs are being designed now and they will get a way to convey the
> tags.

Julian,

Perhaps, I should try to make a better effort to come across more
clearly :-) The linked commands require task tags to be generated by the
SCSI ULP (which is an O.S. component, out of the control of HBA vendors
usually). Most O.S. SCSI ULPs do not generate task tags (or OX_IDs) but
leave this responsibility to the LLPs.

Hence, iSCSI HBAs being designed now makes no difference to this
picture. The O.S. ULP implementations don't need to be re-written for
iSCSI (one would hope!) and therefore, O.S. ULP architectures [that
exist today] prevent the usage of linked commands. (Also, the common
feeling is that since linked commands are not used, why change ULPs to
do otherwise.)

> The question I asked myself when introducing a restriction was always not
> why not restricting but rather why restricting.

Targets need a relaible guarantee that once an initiator issues an Abort
Task for a task/command, it will receive no further PDUs for that task
upon completion of the Abort Task.

In the absence of a mandate that forces initiators to comply to the
above, targets cannot reliably release & re-use their I/O resource since
they could get stale PDUs on that task later.

That is the reason I am requesting that initiators be mandated to apply
connection allegiance to their abort task.

> As for abort as linked command can
> exist only one at a time send the abort task wherever the current command
> is and don't initiate the next. Did I miss something?

I agree that linked commands treatment would be no different than normal
commands. IOW, connection allegiance per command should suffice, as long
as the abort task is included within its purview.

> The tags will be needed for recovery as well (I know that you think that
> isn't necessary either!).

On the contrary, I do believe that task tags need to be sent in the
Abort Task and this should not be an issue. The LLP is aware of the I/O
that timed out, its task tag and it generates the Abort Task PDU and
populates the task tag. This is standard practise and nothing different
here for iSCSI.

Regards,
Santosh
 - santoshr.vcf

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 23 Apr 2001 09:15:30 -0400

Julian,

> Is this true for all OS's?  Is it a verified fact or foloklor?

In my experience it's fact.  I have never used a SCSI stack which both
supported AND used linked commands.  Like some others here, I always
assumed AIX might :^) Ralph has pointed out that T10 is well aware
that the feature is not popular.  There are other ways of
accomplishing the same thing that are less likely to blow up in your
face.

> Is it so also for the new MS StorPort driver?

I don't know, but I'd be really surprised if they did use linked
commands.  You have to be pretty nuts to rely on a feature that's not
even exercised by most SCSI implementations.

Steph

---

From: Mark Mokryn <[email-masked]>
Date: Mon, 23 Apr 2001 16:48:07 +0300

> accomplishing the same thing that are less likely to blow up in your

According to the Shark SCSI spec, from the inquiry data specifically for
an AIX host, linked commands are not supported, both for SCSI and FCP.

-mark

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 23 Apr 2001 09:36:21 -0700

Stephen,

Unlike random access devices, sequential access devices operate with
relative addressing.  For random access devices, this is a seldom used
option.  There is a requirement to bind commands together to ensure order of
execution on these devices.  By popular, you mean not sequential?

Doug

---

From: Mark Mokryn <[email-masked]>
Date: Mon, 23 Apr 2001 20:17:22 +0300

Doug,

Whether or not a device uses relative addressing has nothing to do with
command linking. A LOCATE command moves the head, and a following READ
reads the data. Using command linking, relative addressing, etc. does
not protect the sender of the above commands from another command, sent
by that initiator or any other, which may move the head, and thus cause
the original READ to get the data from the wrong place. There is no
protection between the first and any subsequent commands under command
linking. Thus, the proper way to use LOCATE and READ is with
RESERVE/RELEASE. I assume that it was in order to settle this confusion,
that FC-TAPE decided to ban linked commands.

-mark

-- 
Mark Mokryn      SANgate Systems Inc.      [email-masked]
Phone: +972-9-8919821                Mobile: +972-54-270030
Fax: +972-9-8919449                  http://www.SANgate.com
P.O. Box 1486 41 Hameyasdim St., Even Yehuda 40500 Israel

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 23 Apr 2001 15:06:05 -0700

Mark,

I have little doubt that what you are saying is true for Fibre-Channel.
Much of the confusion seems to stem from the choices in architectural
models.  FC found a solution selectively using CRN and reservation. iSCSI,
choosing to support multiple connections, has then required more extensive
use of serialization.  For devices that can only handle one task at a time,
linking is assured at providing the desired results within parallel SCSI.

One view with the general provisions at providing non-idem potent means of
commanding a device expands into a general discussion of ensuring
synchronization of server state.  This is an obligation of the transport
that is not met with connection allegiance alone.  There are many means of
accomplishing this goal.  With respect to linking, I was simply correcting
the language used to describe command allegiance to a connection.  Unless
linked commands are banned from SCSI, allegiance as now described for iSCSI
does not apply to the task.  As there is never more than one outstanding
command active within a linked command set, iSCSI should have no difficulty
in providing this feature.

What happens at the application and how that translates into the transport
is something the proposal is to provide.  Backup applications are behind the
paradigm shift so do not expect the application to conform to your
expectations.  From the requirement proposal, scanners and printers and
mechanical loaders will need workable solutions within iSCSI.  Should the
transport be able to understand the commands for all of these devices, some
of these devices, and what of devices using vendor unique commands or wholly
new commands?  In my view, the transport should not respond to or modify the
SCSI layer.  There are techniques that make no assumptions about the SCSI
layer content.

Doug