Really getting rid of AEN
Edward A. Gardner
eag at ophidian.com
Tue Jan 7 12:03:17 PST 2003
* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
AEN, as presently defined by SAM and SAM-2, is fatally flawed. The problem
is its interaction with the Unit Attention system. Sending an AEN is
specified to clear the UA. With a non-interlocked bus (i.e. anything other
than traditional parallel SCSI) the following would occur if AEN were enabled:
1. Target detects a UA (e.g. media change) and sends AEN, clearing the UA.
2. Initiator sends a command that alters the media.
3. Target received and processes the command, corrupting the media.
4. Initiator receives the AEN and realizes that its too late.
In other words, AEN on a non-interlocked bus defeats the entire purpose of
having a UA.
Going forward, all SCSI transports are non-interlocked.
One could define a mechanism to report asynchronous events that does not
clear Unit Attention, such as the SRP AER mechanism for Infiniband. Such a
mechanism was suggested for SAS. A major vendor's device groups objected
to the context overhead needed to keep track of which initiators should /
should not get the AER. Attempts to develop alternatives bogged down as
they proved complex, unreliable or both.
At present AEN is being removed because it is unworkable (well, that's my
opinion, and I wasn't there for the vote, but I suspect it is what underlay
the vote). Good move. Now what about linked commands? :-)
There is no champion for an alternate AER mechanism. That is, no initiator
vendor both willing to implement an alternate and waving purchase orders at
target vendors to "encourage" them to implement it as well. The market has
found alternatives, e.g. polling in small configurations, SRP AER in
Infiniband, the FC name server and RSCN for FC. Until there is a champion
demanding another alternative, there is not much point in wasting time
At 16:42 06-01-2003, JimMcGrath at oaktech.com wrote:
>* From the T10 Reflector (t10 at t10.org), posted by:
>* JimMcGrath at oaktech.com
>What is suppose to replace AEN (aka AER) going forward? That is, how does
>a target (device server) notify the initiator (application client) of a
>change in status unrelated to a command, and especially without awaiting
>for a command?
>This capability is not physical protocol related, and I don't think is
>device type related, and so should be in SAM (if not, then what document
>will it be in?)
>PS while I saw the notice of the decision (and vote) to remove AEN in the
>minutes, I did not see a proposal on the topic (which would usually address
>these sorts of issues).
Edward A. Gardner eag at ophidian.com
Basil Networks 719 593-8866 CO voice
1262 Hofstead Terrace 719 210-7200 cell
Colorado Springs, CO 80907 408 635-8741 CA voice
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10