Re: iSCSI Autosense

[julian_satran@il.ibm.com]

Ralph,

How are volume change events supposed to be treated with CA, ACA and
autosense (or for that matter any Async. Event that intends to convey to an
initiator state information that the initiator should be aware of before
sending commands - i.e. how is state sync. achieved)?
I was under the impression that this is one of vestigial uses of CA.

It is obvious that autosense is fine but until I can't be convinced that it
is completely
orthogonal to CA use (or to some other mechanism that can assure state
sync) I would
be reluctant to force it.

If state sync. is provided by some other means that I will be happy to
oblige and assume
autosense is always there.

Thanks,
Julo



Ralph Weber <ralphoweber@compuserve.com> on 30/08/2000 06:12:53

Please respond to ENDL_TX@computer.org

To:   IPS Reflector <ips@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: iSCSI Autosense




This is going to be fun, trying to respond to all the information
and misinformation that's been bandied about today.

David Black's note is correct.  The method for bridging a CA-only
(Contingent Allegiance only) device to an Autosense representation
of that device is well known and trivial.  In addition to being
documented in the requirements, the method is documented in the
first paragraph of 5.3 in draft-satran-iscsi-01.txt.

I have two minor complaints about the 5.3 wording.

1) The method will work all the time, so the suggestion
that it 'may' work is incorrect.
2) I would prefer that the REQUEST SENSE command be explicitly
mentioned not alluded to.

As regards CA, let me restate my position more emphatically.
CA is a historical artifact that dates to the single byte of
status model employed by the parallel SCSI bus.

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.

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.

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.

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.

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.

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.

ACA is more akin to the SCSI-2 ECA (Extended Contingent
Allegiance) than it is to either CA or Autosense.  The
assumption in ACA and ECA is that the initiator needs to
send several commands to the target in order to cleanup
whatever error occurred.  The most frequently cited
excuse for this is the cleanup needed when a tape writes
past the EOT (End Of Tape) reflective strip.

Thanks.

Ralph Weber
ENDL Texas