Re: iSCSI Autosense

[Ralph Weber <ralphoweber@compuserve.com>]

Douglas,

I am very pleased to see closure on the issue of whether or not
it is possible to build a reliable bridge between a packetized
protocol and a parallel SCSI device that supports only CA (Contingent
Allegiance).  Agreement on that point was clearly a critical step
between previous discussions and making Autosense the modus operandi
of iSCSI.

} > To the best of my knowledge it is extremely difficult to
} > implement the CA model in a packetized transfer model because
} > the CA condition is cleared by the next command to arrive
} > at the target regardless of what kind of command that is.

} Not true.  Only for the nexus is this true.

Yes, I am assuming that only a single I_T_L nexus is involved.
Unless there are some iSCSI constraints that I don't know about
(see below), that seems like a reasonable assumption.

} > Since most packetized protocols allow several commands to be
} > in flight concurrently between initiator and target, the most
} > probably case in a packetized protocol is that an in flight
} > command will clear a CA condition long before the initiator
} > finds out about it and has a chance to fire off the needed
} > REQUEST SENSE in to get the sense data.

} These in flight commands are a different nexus such that Sense
} data is not lost.  If the device can not maintain separate Sense
} information BUSY is returned.

Are you suggesting that iSCSI prohibits more than one command from
being in flight from a single initiator to a single target/LUN?  I 
have not read anything in the iSCSI draft that would suggest this.
I find it difficult to believe that there is such a limitation in 
iSCSI as it would be a horrific performance bottleneck.

} > The bottom line here is that Autosense works for packetized
} > protocols and CA does not.  Since it is trivial to translate
} > a packetized Autosense front end to the CA behavior of an
} > older backend SCSI device, the right thing for iSCSI to do
} > is to make Autosense mandatory and not to provide any way
} > whatsoever to disable it.

} iSCSI does provide a means to disable it, but not to refuse it.

What is the point of disabling Autosense if the only result is to
put iSCSI in a dysfunctional mode of operation?

} > The fact that SAM is written with a preference for CA is
} > (like CA itself) a historical artifact.  So long as the
} > wording continues to be correct, it is unlikely that T10
} > will change the wording (if it ain't broke don't fix it).
} >
} > However, the ancient leanings of SAM should not under any
} > circumstances be used as a justification for iSCSI support
} > for a CA-like interface.  As noted above, CA doesn't work
} > for packetized protocols like iSCSI.

} A mistaken conclusion.

I have no response to such a slander on my knowledge of SCSI
that lacks even the decency to include an explanation.

} > ACA (Auto Contingent Allegiance) is absolutely positively
} > NOT the super-duper, all fixed up for a packetized world
} > brother of CA.  ACA is orthogonal to Autosense and actually
} > has no place in this discussion.

} Odd, but error control and reporting does not seem orthogonal.

But they are.  Error reporting means getting a description of
the error from the place where the error occurred to the place
that needs to know that the error occurred.  Error control is
an embellishment that obliges the place where the error occurred
to cooperate with some other entity in resolving the error.

Error reporting is a necessary basic feature.  Error control
adds additional complexity based on the assumption that the
system designers cannot adequately define error processing
so that the point of error detection takes all necessary
recovery steps before reporting the error.

} > IN ALL CASES, ACA is optional.  Simply return 0 in the
} > NormACA bit (bit 5 byte 3) of the Standard INQUIRY Data
} > and you don't support ACA and you are expected to refuse
} > to process any CDB with the NACA bit set to 1.

} For a means of get things to stop, some mechanism should exist.
} This becomes difficult by suggesting refusal of Autosense is a
} bad choice.  ACA may not exist for this purpose if you allow
} older devices.  I suggest that there be a means to refuse
} Autosense.  If the driver can not support this option, it can
} refuse the device.

Absolutely correct, "a means for get[ting] things to stop" must
be provided for in the standard.  For a packetized protocol,
the tools are:

  1) no stop - Autosense
  2) stop - ACA

Like bridging Autosense for a CA-only device, bridging ACA for a non
ACA device is possible although not as trivial as Autosense.  Stated
simplistically, bridging software monitors the NACA bit, CHECK CONDITION
status returns and performs the functions that an ACA capable device
would.  Complexity arises only when the NACA bit is not a constant
value, so to keep this short I'll consider only the case where NACA
always equals 1.  Note, the case where NACA always equals 0 is not
interesting because that means ACA is never used.

Assuming that NACA always equals 1, the bridging software takes the
following steps upon receipt of a CHECK CONDITION status from its
non-ACA endpoint device:

   1) Establish a state on the I_T_L Nexus that causes all newly
      received commands to be immediately returned with an ACA
      ACTIVE status unless the ACA Task Attribute is specified
      in the SCSI Command packet (see 3.2.2 in draft-satran-
      iscsi-01.txt).
   2) Send a REQUEST SENSE command to the endpoint device.
   3) Package any previous command status with the sense data
      received as a result of the REQUEST SENSE command in a SCSI
      Response packet (see 3.3 in draft-satran-iscsi-01.txt) and
      send the packet to the initiator.
   4) Continue processing incoming SCSI Command packets as described
      above until one arrives with NACA equal to 0 (this is where
      things get dicey) or until a SCSI Task Management Command
      packet is received with the Clear ACA function specified
      (see 3.7 in draft-satran-iscsi-01.txt).

N.B. Steps 1 and 4 are the 'error control' capability discussed above.
Steps 2 and 3 are the 'error reporting' capability and they are
incidentally the same steps the bridge would be required to perform
if ACA were not in use.  The two are orthogonal.

Thanks.

Ralph Weber
ENDL Texas