SCSI Commands & Architecture Class Results
I just thought I would post the results of the SCSI training class that was held about a week ago. First I would like to thank the students – without them, this class could not have gone so well. Everyone had lots of questions about various SCSI related topics, including:
- How to interpret SCSI Command fields?
- What happens when a command doesn’t work?
- What are the SCSI Status responses that occur for different conditions?
- How do I decode SCSI Sense Data?
- How do I read or decode a SCSI analyzer trace?
- How can I read a Fibre Channel analyzer trace?
I know that last one may not seem like a “SCSI thing”, but when you are looking at SCSI FCP portions of the trace, we discover that 99% of the information is SCSI related. After all, Fibre Channel is just SCSI over another connection. I guess the same can be said if you are using iSCSI or SAS too.
I believe the high spot of this class, at least for me, was going over analyzer traces that helped to reinforce the concepts of the course. Some of these concepts were:
- How SCSI connections are made
- How to identify what Host (Initiator) and Device (Target) are involved in any command
- How to identify what status is for which command and
- When do we disconnect and reconnect.
At one or two points during the class, I even had some of the students “take control” of the presentation system so that everyone could see what was on their computer screen. And all of this was done without them having to leave their office, or in one or two instances, their home. Everyone used Voice over IP (VoIP), so that we could chat and answer questions in real time. I especially want to thank the students in the Eastern time zone for “working late” when we had to change the schedule. I hope that all of the students enjoyed their “bonus gifts” that were sent to them because of this change.
One last note: If you and a few coworkers would like to take this class, or one of the other SAN training courses offered, please contact me and I will try to arrange a course that is convenient for YOUR schedule.
You can also check the following link to see if there is a “public class” that you may want to attend.
SCSI Training Classes
An Online SAN Training Course – SCSI-3 Architecture and Commands – is coming up starting July 19, 2010. I am scheduled to facilitate this course (I’m the instructor), which is open to anyone, so if you have the need or desire to attend one of my SAN training classes, please go to the link at the bottom of this page to sign up.
It is NOT free, as this is how I make my living, but the price is very reasonable. But if you enter “Greg – Bonus Item” in the “Notes” field of the registration form, you will receive a “bonus item” along with the most current version of the In-Depth Exploration of SCSI book (the book is included with the cost of the class). Since the book and bonus have to be shipped to you, please sign up early enough to arrive (sorry I didn’t post this earlier).
You can see the details of the course by clicking this link, and I will be able to answer your SCSI related questions using Voice over IP (VoIP), so all you will need is your computer with a microphone connected, and we’re good. You could also call in over the phone, but who wants to do that for 4 days in a row, for 4 hours a day. I also attempt humor and tell “SCSI stories” to get everyone involved, and will be decoding protocol analyzer traces to show how SCSI works, what happens when it doesn’t work (that means decoding sense data), that kind of thing. And of course if you have any specific questions, that would be the time to ask them.
These Online Training classes are usually a lot of fun, and you don’t have to travel anywhere, or for some, you don’t even have to leave your home! Just fire up your computer (with relatively high speed internet), login each day, and we can take a deeper look at how SCSI works.
I hope to “see” you soon.
Click Here to Sign Up for the SCSI Architecture and Commands Training Course.
Secure Registration Form
A Nexus, in the world of Storage Networking is a unique identifier. It identifies the components involved in a command or sequence of commands. It is normally made up of the following parts:
Initiator (I), Target (T), LUN (L), and Queue Tag (Q). This is an ITLQ nexus.
Establishing the Nexus
In parallel SCSI (and most storage systems), everything starts on the host side of the system. When a host wants move some data (do a READ or WRITE) it will need to know that a storage device exists, and then build and send a command to it. But there is another SCSI protocol that takes place to connect and issue the command. That protocol is below.
- Arbitration - initiator ID is placed on the bus (usually #7).
- Selection - target ID is place on the bus and target takes control. At this point, an I_T nexus exists.
- Message(s) – target asks for bytes to identify the LUN and Q-Tag (if needed). This is where the full I_T_L_Q nexus is established.
- Command - CDB is sent to the device, which processes the command and controls the flow.
- Data - this is the data movement phase (IN for READ, OUT for WRITE).
- Status - information is sent back to the host (command worked or had an error).
- Message - this tell the host that the command is done.
Once the command is finished, the nexus is “released” and can be used again. This is because the nexus is only needed while the command is in progress.
Disconnect and Reconnect
The protocol shown above shows a single connection, where everything is done during that connection. But where the nexus really comes into play is when there is a disconnect and reconnect after the command had been issued. This is one of the biggest benefits of “networked” storage. While the storage devices are disconnected, the host can connect to another device and start a different command with it.
The important part is that while a command is still in process (no status yet), the nexus remains and is known to the host. The storage device also can do “slow stuff” while disconnect, such as moving the heads, spinning the platters, that kind of thing. When the device has the data ready (READ), or has resources to accept more data (WRITE), then it will use the same nexus values (I_T_L_Q) and will reconnect to the original host to continue the command sequence. This can happen multiple times for a single command, and the nexus remains until the command is complete.
Categories:
Glossary Tags:
Nexus