RE: iSCSI: Why is ACA optional?

[julian_satran@il.ibm.com]

Jim,

You are correct and this should be taken to T10 as it affects every
transport.

Thnaks,
Julo

Jim McGrath <Jim.McGrath@quantum.com> on 05/12/2000 04:46:21

Please respond to Jim McGrath <Jim.McGrath@quantum.com>

To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Why is ACA optional?





We have discussed this thread before (many months ago).  Then as now the
bigger problem is that ACA will not prevent the execution of the second
command if the first command failed sue to BUSY, QUEUE FULL, or RESERVATION
CONFLICT status.  Basically ACA only works if a Contingent Allegiance
condition exists, which required a CHECK CONDITION status.

We did discuss at the time that something like ACA could be used to cover
all of these conditions.  Is this what people are discussing?  In that case
I suggest we use the term "Expanded ACA" to identify it from "current ACA."

I don't think T10 has taken action on this (if so, I could not find it is a
quick look at the T10 proposals).  And of course an "Expanded ACA" would
not
exist anywhere yet in the installed base.

Note that drivers simulating this behavior is a different issue from native
device support.  Still, I'd prefer to avoid the use of the unqualified ACA
in order to avoid confusion over terms.

Jim



-----Original Message-----
From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
Sent: Thursday, November 30, 2000 9:49 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Why is ACA optional?




Charles,

I agree that ACA is almost a non issue for non-queing devices provided that
initiators  do queuing properly and are aware of the non-ACA behavior.

The burden is then left on the initiator (and it is no small burden for a
large mutithreded initiator).

The only reservation I have is that supporting both ACA and non-ACA is
going to be clumsy and error prone in the hosts and many OS providers  will
not support queueing at the device even when available (as they do today)
and this will in turn negatively affect the perceived performance of
targets.

Regards,
Julo

Charles Monia <cmonia@NishanSystems.com> on 01/12/2000 00:11:20

Please respond to Charles Monia <cmonia@NishanSystems.com>

To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Why is ACA optional?




Hi Julo:

See below.

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Thursday, November 30, 2000 11:55 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Why is ACA optional?
>
>
>
>
> Charles,
>
> It is good enough if it is mandated for new devices - those
> are likely to
> appear with native iSCSI -
> with a wording in the SHOULD class (strongly recomended).
>

In T10, "should" doesn't have the force of a requirement. A device that
doesn't implement the feature can't be declared non-compliant.  What's
more,
strongly recommending an option doesn't even guarantee that the majority of
devices will implement the feature.  In such cases, the buyer's only
leverage is the product purchase spec, hoping in the meantime that the
feature becomes a de-facto requirement of the market.  Would that meet your
needs?

As an aside, it's been suggested that iSCSI devices need only support ACA
if
they implement command queuing.  That sounds reasonable to me.

Charles
> Regards,
> Julo
>
> Charles Monia <cmonia@NishanSystems.com> on 30/11/2000 21:29:45
>
> Please respond to Charles Monia <cmonia@NishanSystems.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: Why is ACA optional?
>
>
>
>
> Hi Julo:
>
> A blanket requirement for mandatory ACA support would make almost all
> legacy
> devices noncompliant.  I don't think the T10 community would
> be willing to
> support that any time soon.
>
> Charles
> > -----Original Message-----
> > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> > Sent: Wednesday, November 29, 2000 9:21 PM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: Why is ACA optional?
> >
> >
> >
> >
> > Charles,
> >
> > That is probably the path we should be taking although I
> > wonder why would
> > T10 not mandate as it
> > as this thing affects all interconnects. We might then (as
> > with the name
> > mapping) see it happen in T10.
> >
> > Regards,
> > Julo
> >
> > Charles Monia <cmonia@NishanSystems.com> on 30/11/2000 00:06:29
> >
> > Please respond to Charles Monia <cmonia@NishanSystems.com>
> >
> > To:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > cc:
> > Subject:  RE: iSCSI: Why is ACA optional?
> >
> >
> >
> >
> > Hi Julo:
> >
> >
> >
> > > -----Original Message-----
> > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> > > Sent: Wednesday, November 29, 2000 11:18 AM
> > > To: ENDL_TX@computer.org
> > > Cc: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: Why is ACA optional?
> > >
> > >
> > >
> > >
> > > Ralph,
> > >
> > > That is an interesting argument.
> > >
> > > However, now that disks have become more complex and can
> > > queue tasks how
> > > would you
> > > handle having one task rejected because the queue was full
> > > and the next
> > > (still in flight) accepted because
> > > some slot became available?
> > >
> >
> > The case you mention certainly addresses most but not all
> > such occurences.
> > There are other transient exceptions, such as commands that
> > terminate with
> > a
> > BUSY or ACA ACTIVE status, that have the same effect but do
> > not themselves
> > result in an ACA condition.
> >
> > > And this might even happen inside the host (possibly a large
> > > SMP) that with
> > > SMP would not have to care coordinating tasks but without ACA
> > > will have to
> > > strictly serialize access.
> > >
> > > IMHO TODAY not mandating ACA is a mistake (IBM 360 disk
> > > controllers had it
> > > 30 years ago for the very reason I quoted).
> > > I any case iSCSI can do little to ease the pain - except to
> > > point out to
> > > those that plan using disk subsystems without ACA to rely
> on status
> > > numbering and issue commands one by one.
> > >
> >
> > I believe iSCSI always has the option of making ACA support
> > mandatory (in
> > the same way that autosense support is mandatory).  If so,
> > for practical
> > reasons it will be up to the initiator's iSCSI stack to do so
> > in a way that
> > is transparent to the parts of the I/O driver stack above the
> > iSCSI layer.
> >
> > Charles
> >
> >
> >
>
>
>