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.
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:
Categories: Glossary Tags: SCSI, Sense Data
SAN Training Travel
As a SAN Training Instructor, one of the things I get to do (or have to do, depending on your point of view) is to travel to different parts of the United States and other parts of the world.
Last week, I did some “minor” travel, at least for me. You see, I live in the East Bay area of the greater Silicon Valley and got the chance to visit the Solution Technology facilities to present an iSCSI Protocol Training course. Since my home is over 50 miles away, and about 75 minutes from the site (or more if there is any traffic at all), it was decided that I would “stay over” between the days of the class. Considering the price of gas and the wear on the vehicle (and me) of making one round trip vs. three, then I think I broke even. But not having to deal with the traffic each morning and evening really allows me to concentrate on how the class is going and think about the students’ needs for the next day of the class.
And there is another benefit that I would like to share with you – that is the view from Mill Street early in the morning after I made my 2 minute commute from the hotel to the office. Check out the pictures below.
View from Mill Street toward Highway 9 - Ben Lomond, CA
This is the early morning view from the street that runs past the office. Notice the fog that covers the tops of the trees. I had to get a closeup view, which is shown in the next picture.
Fog in the Trees of Ben Lomond
As you might be able to tell, it has been a good ‘rainy season’ this year (yes, we need the water) and you can probably see the wet street in the first picture.
I really love this area for all of the trees and the chance to get away from the typical ‘busy’ environment of the usual places I go to do training. It is also very relaxing to be able to get outside during breaks and lunch time, at least when the son comes out. I’m sorry I didn’t get any pictures of the river that runs behind the office, but next time I’m there I will put that on my to-do list.
We are not completely isolated here (yes most cell phones do work here), but there is a chance to get away from the typical ‘110 mph rush’ that seems to be everywhere down in the valley. So the next time you need a SAN training class, give us a call and come visit us in Ben Lomond for a few days. You will be glad you did!
Incoming search terms for the article:
- san storage pictures
- Ben Lomond CA
- cache:ARmwI9d_yFgJ:www santrainingblog com/2010/03/iscsi-training-course/ scsi_status=22
- storage area network training in bay area
- silicon valley storage training
- Silicon Storage Area
- san training in us
- san area network pictures
- best storage training blogs
- storage san training
iSCSI Training Course
I just finished an iSCSI Training Course last week at the Solution Technology Training Facility, and I must say that I had a great time.
First, I want to thank the students that joined me, for their participation and enthusiasm. When I do SAN protocol training, I always encourage questions at any time, and there were quite a few right from the start, all the way through the last day.
As with many of the iSCSI classes that I do, we start off with where iSCSI comes from (evolution of SCSI) , along with the applications and environments where iSCSI makes sense as a SAN solution.
Then we start to look at how iSCSI is actually “done” – that is, how SCSI Phases, Commands, Data, Messages, and Status are encapsulated into iSCSI Protocol Data Units (PDUs) and are sent back and forth over a TCP connection, to get some kind of work done (storing and retrieving data). We even go into the details of all the iSCSI PDUs. That takes up most of the first day, but that is when the fun begins, at least for me.
The “fun” is when we start to look at iSCSI protocol using a protocol analyzer. In my classes, we use Wireshark, and start by looking at some captured traces that I supply. We do this so that we can get to know the analyzer and the iSCSI protocol in a controlled way. We even add color to our traces so we can easily recognize iSCSI activity. Once that is done, it is time to start building our own iSCSI SAN and capturing ‘live’ traces of what is going on. This is the basics of what makes up our own iSCSI Lab, which is unique every time we do them.
The iSCSI Lab is made up of one or more iSCSI Initiators, one or more iSCSI Targets, and of course the infrastructure (network) to connect all of the components together. These components can be hardware, software, or a mix of the two.
Last week, we did a “mostly software” lab, but all of that has to run on computers (hardware). And like many other labs I have done, there were issues with some of the hardware. The good news is, we had a chance to do a little debugging and had other hardware that we could use. As a result, I believe one of the key objectives of building an iSCSI SAN was achieved – that is how to use the information and tools available to debug any issues that may come up.
After a relatively short time, we had the iSCSI Initiator software installed, and the iSCSI Target software installed on working computers. Then we did a “controlled exercise” to capture analyzer traces as the students attempted to connect and log into the targets. Again, we were challenged by having basic connectivity (we could ping from each machine), but there were issues with doing the TCP connection and iSCSI Login sequences. Once again, we used the analyzer traces that we captured to debug the issue and get successful iSCSI Login PDUs flowing between the initiators and targets.
There were a few other challenges, such as Disk Administration and configuration duties, but once that was done we had a working iSCSI SAN where data was moving back and forth across the network. After all of this “work” was done, we had a great time capturing traces and looking at the differences between different iSCSI Initiator implementations in detail. I must say that it was interesting to see how different people “do the SCSI thing” in the world of storage.
There were other challenges involving weather, wind, and trees, but that will have to covered in a future post.