|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: About CA, ACA, and AutoSense
I keep getting requests to sort out CA (Contingent Allegiance), ACA
(Auto Contingent Allegiance) and AutoSense. Since what I do mostly
is write articles for the ENDL Letter, I've taken these repeated
requests as a suggestion that an article dedicated to the subject
be cobbled together.
The ENDL Letter publisher, I. Dal Allan, and I have produced the
article reproduced below in the belief that it will prove useful
to everyone who is wresting with porting SCSI to IP.
As you peruse the article you will find some pretty deep history
on the topic of CA, ACA, and AutoSense. The ENDL Letter has been
published since 1984. If you are interested in subscribing to the
ENDL Letter please contact me directly.
Thanks.
Ralph Weber
Editor
ENDL Letter
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Distributed with Permission of the Publisher
ENDL Inc. grants the right to distribute the article entitled "WHERE IS YOUR
ALLEGIANCE" to the IETF (Internet Engineering Task Force). Reproduction of
the contents in any published form shall attribute ENDL as the source.
ENDL Inc. specializes in marketing and engineering consultation on interface
issues, systems architecture and storage technology. The ENDL Letter
provides subscribing clients with detailed coverage of industry activities
in a style that is suited to both marketing and engineering personnel.
The ENDL Letter is published monthly by ENDL Inc.
The article which follows was prepared by ENDL Letter editor Ralph Weber of
ENDL Texas and edited by I. Dal Allan of ENDL.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(C) Copyright 2001 ENDL
WHERE IS YOUR ALLEGIANCE
Several times in recent months there have been discussions about Contingent
Allegiance, Auto Contingent Allegiance, and AutoSense. While most of these
exchanges have originated from IPS (IP Storage) folks trying to learn the
SCSI ropes, the level of confusion indicates that a review might be helpful
to our readers.
History
In the beginning there was CA (Contingent Allegiance) and though everybody
did not like it, there was no doubt that CA was a fact of SCSI-2 life. The
event that forced CA into existence was the decision to separate telling the
initiator an error had occurred from telling the initiator what kind of
error it was that occurred.
o First, tell the initiator that an error occurred (Check Condition status)
o Second, if the initiator asks, tell the initiator what the error was (the
Request Sense command and returned Request Sense data)
Since the earliest days of SCSI there were those who believed it would be
best to send both Check Condition status and the Request Sense data in the
same Status phase. There was opposition though, primarily from those who
believed that by including the controller in the device there would be no
errors and providing sense data would be so exceptional it should be done as
a separate action.
And as for those who believed so sincerely. Why list names, when we can be
politically incorrect and stamp a stereotype? Disk drive vendors dominated
the SCSI committee then, as they do now, and as a group there is little or
no appreciation of the complexities involved in error recovery of different
device types.
History repeated itself when Fibre Channel development fell into the same
trap, and designed around disks in the PLDA (Private Loop Direct Attach)
Technical Report. PLDA is why FCP-2 (Fibre Channel Protocol) was needed, to
add a whole new way of doing error recovery in order to handle tape drives.
There was one memorable convert from the side of separate actions. It was
nowhere near as dramatic a conversion as on the road to Damascus, but when
Paul Nitza (then with Emulex) declared war on Request Sense during SCSI-2,
he shocked the members.
Paul had always been a target kind of guy, but when he was assigned to write
initiator drivers he discovered just how the lack of AutoSense made life
miserable for the host. Charged with zeal, Paul came armed with enough fire-
power to convince the committee to incorporate his ideas into at least one
of the draft revisions.
SCSI WORKING GROUP MARCH 18-20 1987
Bundled into Paul Nitza's command queuing proposal was AutoSense;
a method which allows the target to automatically return Sense
Data upon a Check Condition. If an error occurs during execution
the target follows the procedure of:
Status Phase Check Condition
Data In Phase Sense Data
Message In Phase Command Complete Message
Harlan Andrews (Apple) had serious reservations about this
sequence because a Data In phase could mislead initiators (host
bus adapters) into transferring the Sense Data into the host
system memory behind the completed data transfer.
Paul's justification for including AutoSense as part of command
queuing is that he does not want the target forced to retain all
the status associated with queued commands. At present, SCSI
requires that sense be retained until the next command but in a
command queued environment, sense would have to be retained until
a tag was re-used. Bob Snively (then Adaptec now Brocade) felt
retaining one byte of sense per tag was a minor burden as it does
not require much buffer storage.
Unfortunately for SCSI users, Paul decided to leave Southern California and
left Emulex to head East to Ohio and set up his shingle as a consultant. No
client came along to support/subsidize his continued participation in the
committee, and without Paul as champion, the initiative faltered and died.
SCSI WORKING GROUP JANUARY 6-8 1988
Jim McGrath (Quantum) nominated himself as leader of the AEN
(Asynchronous Event Notification) expunge task force by declaring
similar distaste for AutoSense, and adding that to his campaign.
His rationale is that the AutoSense justification is based on
performance, yet the number of errors in a disk system are so low
it cannot possibly make any difference.
"AutoSense adds one more mechanism to an already over-burdened,
complex structure to handle an event that might happen only
once a week."
X3T9.2 SCSI MEETING FEBRUARY 22-23, 1988
AutoSense died, and is to be removed from SCSI-2. There were no
protests from anyone in the tape area.
Request Sense remained as a burr in the side of progress, because command
queuing brought with it the attendant problem of how to make sure Request
Sense data hung around long enough to be collected by Request Sense. Assume
two commands in the queue get errors, what then? You have to get inventive,
so CA was spawned to make the target stop doing things which might produce
more errors whenever it has to send a Check Condition to the initiator.
CA begins when the Check Condition is sent, and stays in force until the
next command arrives from the initiator to which the Check Condition was
sent. Basically, the initiator gets exactly one chance to send the Request
Sense command and learn what error caused delivery of the Check Condition.
A number of factors kept AutoSense alive in the waning year of SCSI-2, and
CA was one of the primary reasons.
SCSI WORKING GROUP JANUARY 9-11 1989
Steve Goldman (then DPT) had left the X3T9.2 plenary in December
vowing to return in another attempt to obtain Terminate Immediate.
Return he did, with a thick document and Paul Nitza's (then OTL)
support: obtained by coupling Terminate Immediate with AutoSense.
A historical note here, AutoSense had been proposed by Paul early
in SCSI-2, and it had been removed after he left Emulex, stopped
being an editor, and missed several meetings.....
When Paul wanted to know why AutoSense had been removed from
earlier SCSI-2 revisions he sparked a debate on the merits of
AutoSense saving any time. Actually, little is saved as far as the
target is concerned. The target may save a little on responding to
selection plus parsing of a Request Sense command; but this is not
the right place to focus on time savings.
Paul struck on part of the problem: a long initiator delay if
beaten out on bus arbitration by a higher priority device. This is
likely to happen only on heavily-used systems and did not seem to
concern too many members.
Gary Stephens (IBM) mentioned the time it takes an initiator to
re-dispatch another command to Request Sense, but it seemed to be
regarded as being of even less importance than Paul's comment.
NOTE: Dispatch time can be a big number in many operating system
environments, and can easily fall into the 2-8 msec range.
Debate ended with AutoSense being made a SCSI-3 item. Resistance
appears to be based more on emotion and target microcode than on
system considerations.
Six months later there still had been no final, irrevocable decision on what
to do with AutoSense.
SCSI WORKING GROUP JULY 10-11 1989
As John Lohmeyer (NCR) worked his way down the list of "oldies,"
he asked:
"If everybody keeps asking for AutoSense, how come we keep
voting it out?"
Despite several attempts over the last two years, AutoSense has
never made it, and the conclusion was that nobody had thoroughly
thought through the problems of integrating AutoSense in a
backwards-compatible manner.
Gary Stephens (then IBM now FSI) suggested extending Status phase
to include Sense Data...
The reticence to incorporate AutoSense left all the eggs in the CA basket.
While a CA is in force the target is prohibited from doing more work on the
commands in its queue. This restriction is not to be nice to the initiator,
it is to make sure the target does not do something that might generate a
second Check Condition and corrupt the original Request Sense data.
While the CA is in force, the target is prohibited from accepting commands
from an initiator other than the one to which the Check Condition status was
sent. All such commands get returned with a Busy status, and again the goal
is to prevent the target from getting into a spot where the original Sense
data becomes corrupted.
When the initiator to whom the Check Condition status was sent finally sends
a command, the CA is cleared and all proceeds according to the rules defined
by the Control mode page settings. Typically, everything proceeds as if the
CA had never happened. Request Sense provides the details about the cause of
the Check Condition and the initiator deals with the error.
What if the command sent by the initiator is not a Request Sense? Say bye
bye, because the Request Sense data is sent to the bit bucket and everything
continues on as if the CA had never happened. The initiator has one and only
one shot to retrieve the Request Sense data (use it or lose it).
These rules are simple, ironclad, and easy to follow but things took their
first twist for the complicated when Gary Stephens (then IBM, now FSI) had
an idea.
"Why can't we have a CA that lasts until the initiator says to return to
normal?"
"That way if complex error recovery is required in response to the Request
Sense data, the target will stay in a CA-like state until the recovery is
all completed."
Thus was born ECA (Extended Contingent Allegiance). The major beneficiary
was intended to be tapes, so processing at end of reel could be accomplished
under an ECA state with the yet-to-be-completed writes held in the queue
until the new reel was mounted and ready to receive more data.
ECA was always optional with the initiator using a Control Mode Page bit to
tell the target that ECA was to be used instead of CA for handling Check
Conditions. When ECA was in effect, the target told the initiator that ECA
was being entered by sending an Initiate Recovery message and the initiator
told the target to exit the ECA state by sending a Release Recovery message.
Between the time those two messages were sent the CA-like state was extended
to become ECA, with the initiator being able to send as many new untagged
commands as it liked while the ECA was in effect.
And how important was ECA in the greater scheme of things? Let's be generous
here and say that one or two companies implemented ECA because they thought
it was a great idea, another one or two implemented it because a customer or
supplier told them to, but otherwise ECA was generally unloved.
The combination of CA and ECA was livable for the SCSI-2 parallel bus but
times changed dramatically when Fibre Channel and its other serial protocol
brethren came along. Serial SCSI stirred the murky waters into a veritable
froth of confusion.
All was not well in parallel land either. George Penokie (then IBM and now
Tivoli) entered stage left to tilt at one of the longest spinning windmills
in SCSI history. George clarified the queuing model, and gave it a new coat
of polish to carry it forward into the IU (Information Unit) world of Fibre
Channel. Nailing this task down took a whopping 18 revisions of the proposal
and nearly two years of monthly multi-hour excursions to the front of some
meeting room somewhere to be pummeled by proponents of this or that.
ECA proponent Gary Stephens was convinced his day had come.
"With IUs in transit in both directions, you're going to have to use ECA
to block new commands until the initiator can find out that it's got to
send a Request Sense command to get the data."
"CA will not be good enough because a command in flight will look to the
target like it should be the Request Sense command needed to collect the
sense data, but it's really just the wrong command at the wrong time."
The packetized protocol of Fibre Channel had no low level messaging between
target and initiator which could carry the Initiate Recovery message. A new
invention was required, and thus was born ACA (Auto Contingent Allegiance).
ACA was one part CA, one part ECA, and one part entirely different.
o Like CA, ACA happened automatically upon delivery of a Check Condition
status.
o Like ECA, ACA stayed in force until the initiator said uncle by sending a
Clear ACA task management function (which translated to a new message on
the parallel bus or a magic bit in a Fibre Channel IU).
o Unlike either of its progenitors ACA created a totally task attribute (or
queue tag) to mark commands that would be allowed to execute during an
ACA state, cleverly called the ACA attribute.
For a while there, it looked like ACA was actually going to get used in the
Fibre Channel world as it was the only game in town to preserve the Request
Sense data until an ACA tagged Request Sense command could be sent to get
the details of why the Check Condition occurred.
As things turned out, ECA inventor Gary Stephens was the unwitting killer of
ACA. This might be hard to explain without some background so here goes with
another flashback to earlier pages of the Happenings to set the stage.
SCSI FORUM MARCH 13-15 1991
Gary Stephens' (IBM) opening was like a pitch for a new breakfast
cereal.
"Introducing! New High Fibre SCSI."
Gary was talking about the SPP (SCSI-3 Packetized Protocol), a new
twist from the same folks who brought us SCSI-1 and SCSI-2........
"Most of the logical elements remain familiar to SCSI fans. The
Message system, Command Descriptor Blocks, Command Parameter
Data, Command Response Data and Logical Block Data are all
present. Regular Status plus a new element, AutoSense are
there."
"I lost my bid for AutoSense in SCSI-2, but now it's back."
Gary had several flow charts of transfers between Initiator and
Target to demonstrate the logic of SPP. He complemented this with
configurations that showed how Fiber Channel can be configured
Point-to-Point, Switched Multi-Point or as a Ring.
"SCSI via the Fibre Channel will be the next revolution in
peripherals attachment technology."
Gary opened up the floodgates.
o In October 1992, Ed Gardner (then DEC now Ophidian Designs) proposed that
an AutoSense capability be added to the 1394 SBP (Serial Bus Protocol).
o Despite opposition earlier in the year, by September 1993, AutoSense had
been integrated into SSA (Serial Storage Architecture) SSP (Serial SCSI-3
Protocol).
AutoSense soon came to be perceived as a solution to nasty situations which
required ACA, as illustrated by this quotation from Bob Snively (then Sun
Microsystems now Brocade) from the SCSI Working Group in May 1994.
"AutoSense is a better solution for non-interlocked protocols
than ACA, and all the serial protocols provide it."
Bob took the necessary steps to make ACA optional, and so far as ENDL knows,
it is unused (to no one's surprise).
The ultimate triumph of AutoSense came when George Penokie and Jeff Williams
(then Hewlett Packard now Seagate) brought a new generation Packetized Prot-
ocol for parallel SCSI to committee. Here is a key point made in the April
1998 Happenings.
The really important thing about the SPI Status IU is that it
contains sense data, thus giving SCSI parallel its first AutoSense
capability.
Long and Short of It
Given the twisted history of how ACA and AutoSense grew out of ECA and CA,
and because 'Auto' is the first word in both AutoSense and ACA, there is a
lot of folklore around which feature does what and why. Most of it borders
on mythology, and here is the ENDL slice and dice of reality.
There are two general problems to be solved:
o Getting the Request Sense data to the initiator
o Blocking target activity until the initiator has been able to do every-
thing needed to recover from an error
The matrix of problems and solutions looks like this.
+--------------------+
| Solution |
+---------------------+--------+-----------+
| Problem | SCSI-2 | SCSI-3 |
+---------------------+--------+-----------+
| Getting the Request | CA | AutoSense |
| Sense data | | |
+---------------------+--------+-----------+
| Blocking activity | ECA | ACA |
+---------------------+--------+-----------+
o CA makes sure an initiator can get Request Sense data by blocking activ-
ity for an extremely limited period of time i.e. until the next command.
o AutoSense makes sure the initiator gets Request Sense data the way some
folks always thought it should be done, by co-locating the Request Sense
data with the Check Condition status.
Despite the commonality of names, ACA is not a special case of CA, ACA is
the SCSI-3 version of ECA. Once you accept this it comes as no surprise to
learn that ACA is implemented with about the same lack of enthusiasm as ECA.
(C) Copyright 2000 ENDL
Home Last updated: Tue Sep 04 01:05:31 2001 6315 messages in chronological order |