Posts Tagged ‘SCSI’

Asynchronous Event Notification (AEN)

Asynchronous Event Notification (AEN) - Note: this is now referred to as Asynchronous Event Reporting (AER).

Asynchronous Event Notification (AEN) is a process or procedure that may be used by SCSI targets to notify a SCSI initiator of “events” that occur in the target, when the target is NOT executing an Active Process (a command). An example of an “event” could be a Unit Attention caused by removing a CD or DVD from a player or recorder (medium is removed). These events normally result in a Contingent Allegiance Condition (CAC).  Without AEN, the initiator will not know of any events until it tries to send another command, or another command is processed from the queue.

The hard part of AEN involves the target becoming a “temporary initiator” and being able to use the SEND command to tell an initiator about the event. This initiator would also have to become a “temporary target” to be able to receive this report. Since devices rarely change rolls, especially initiators, this is a seldom used feature of the SCSI world.

But the good news is, with the advent of Serial Attached SCSI (SAS), parts of the infrastructure, called SAS Expanders, have the capability to send and receive “broadcasts” – which can be used to notify “management processes” about different types of events.  This can be loss of synchronization on a link,  a link that comes up or goes down, and the ability to send SCSI event notifications.  Expanders usually also contain another function called a SCSI Enclosure Services (SES) device.  This can also enhance the system by monitoring things like air flow, temperature, and backplane voltages.

If you have any questions about this just let me know by leaving a comment on this page.

Incoming search terms for the article:

2 comments - What do you think?  Posted by Greg - April 26, 2010 at 8:54 PM

Categories: Glossary   Tags: ,

Contingent Allegiance Condition (CAC)

A Contingent Allegiance Condition (CAC) is a SCSI “condition” that exists after there is some kind of problem.  What I usually say during class is “these are big words for ‘Hey – We have an error.’ – or some other kind of problem”.

I often find that if you move the words around, it is easier to understand the concepts from the SCSI standards.  Here is an example:

A Contingent Allegiance Condition is:  a Condition (state) that is Contingent (dependent) upon the Allegiance (connection) between two entities, or components, in a SCSI-based system.

Now for the translation – and I will try to keep it short.  In the universe of Storage Area Networking, which is almost entirely SCSI based, the first thing we have to do to be able to issue a command is to make a connection, between the Initiator, through the Target, and finally to the Logical Unit, or at least the code that represents the Logical Unit.  Making this connection establishes what is called a Nexus – or I_T_L Nexus.  I like to refer to a nexus as a “process ID” – or identifier – for every command within the system.

Since a storage area network, or even a relatively small parallel SCSI system can have multiple initiators, targets, and logical units, it is important to uniquely identify each command, or process, that is sent through the system.  That way, we can keep track of all the commands that have been issued and reconnect them back with the original initiator that issued the command.

So that is where the “Contingent Allegiance” part of a CAC comes in – its all about the Nexus, and the connection that it represents.

Now the “Condition” part is simply a “state” that is not considered “normal”.  You see, when everything works in a SCSI system, the normal “flow” is:

  • Make a connection (establish a Nexus)
  • Issue a command (from initiator to target)
  • Process the command (Target moves data to or from storage, if needed)
  • Receive GOOD status (00h code)
  • Close the connection (Nexus “goes away”)

When something goes wrong, then you do NOT receive GOOD status – you most often get back a CHECK CONDITION status (02h code) from the target.  This is how the initiator is informed that an error occurred.

The other part you are supposed to know is that the target has generated some sense data, which will explain why the error occurred.  And this is where the CAC and Nexus part comes in – the target is supposed to keep the sense information based on the nexus, and that particular command.

What clears this Contingent Allegiance Condition? Normally it is when the same initiator issues another command to that same target and logical unit (remember – its all about the nexus).  Usually, the next command is a REQUEST SENSE command, which retrieves the sense data from the device, and it can be decoded by the initiator.  Based on this sense data, the initiator should take the appropriate recovery action.  What action will the initiator take?  The answer is – it depends.  It depends on the content of the sense data.

Please let me know if you have any questions or comments.

Incoming search terms for the article:

2 comments - What do you think?  Posted by Greg - April 9, 2010 at 4:55 PM

Categories: Glossary   Tags: , ,

SCSI Sense Data

SCSI Sense Data is the information that comes back from a target when either 1) a CHECK CONDITION Status has been received at the end of a Command (using an auto-sense mechanism), or 2) a REQUEST SENSE command has been issue by a SCSI Initiator.

Whenever I do my SAN training classes, this is one of the topics that I always cover – How to Decode SCSI Sense Data.  Becoming a sense data decoder is not that difficult if you know the basic structure of the sense data and the 4 basic steps that I used to decode 95% (or more) of all the sense data that I see.  Below are the basic steps.

Step 1 – Check the Sense Key.  The Sense Key provides “basic” information about the error and is located in byte 2, bits 3-0, of the returned sense data.

Step 2 – Check the Additional Length field.  This field is located in byte 7 and tells you how many more bytes of data are valid (after byte 7).

Step 3 – Check the Additional Sense Code (ASC) and Additional Sense Code Qualifier (ASCQ).  These are bytes 12 & 13 of the returned sense data and provide more detailed information about the failure or error condition.

Step 4 – Check the Sense Key Specific Valid (SKSV) bit, which is located in bit 7 of byte 15.  If that bit is on, it means that there is “even more” detail about the condition that caused the problem in bytes 15-17.  You will have to plug it into another decode table, based on the Sense Key (from Step 1), but in some cases, this can point you to the exact bit and byte in error so that you can debug your problem.

Sense Data Decoder Steps

Steps to Decode SCSI Sense Data

These 4 basic steps can decode up to 95% of all the SCSI error conditions that you will ever see, but there can be even more details, depending on the SCSI device (disk drive, tape drive, etc.) that you are working with.  Master these 4 steps and practice them whenever you can and you will become a SCSI Sense Data Decoder in a relatively short period of time.  If you want to learn how to decode sense data even faster, just let me know and we can get you signed up.

Incoming search terms for the article:

1 comment - What do you think?  Posted by Greg - March 24, 2010 at 4:35 PM

Categories: Glossary   Tags: ,

Next Page »