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 
discussing one.

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
>*
>
>Ralph,
>
>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?)
>
>Jim
>
>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 mailing list